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In this Issue 

While cost containment is certainly the most publicly visible concern in medi- 
cal care today, hospitals are under just as much pressure to improve the qual- 
ity of patient care. Since they can invest in new equipment only every seven to 
fifteen years, hospitals want that equipment to be easy to upgrade and adapt 
to new technologies. In designing HP's fourth-generation patient monitoring 
system, the engineers at HP's Medical Products Group had to deal with these 
and other issues influencing their hospital customers' investment decisions. 
The design of the new system, which they call the Component Monitoring 
System, emphasizes modularity, flexibility, and ease of use while addressing 
the increasing need to measure new patient parameters and to process this 
information using powerful algorithms and data management tools. The article on page 6 introduces the 
system and its overall architecture, while details of the hardware and software architectures can be 
found in the articles on pages 10, 13, and 19. The necessary functions of data acquisition, parameter 
signal processing, display, and system connections are implemented as hardware and software building 
blocks. Application software modules, such as the blood pressure measurement software, can be arbi- 
trarily assigned to any CPU in a loosely coupled multiprocessor system. The applications think that they 
are running on a nonexistent virtual processor. The architecture makes it easy to configure the system 
for both current and future needs in the operating room, intensive and cardiac care units, and other hos- 
pital areas, and contributes to a greatly simplified, low-cost production and test process. Patient param- 
eters such as blood pressure, the electrocardiogram (ECG), blood gases, temperature, and others are 
measured by state-of-the-art modules that can be located close to the patient while the signal processor 
and displays can be in another room, if necessary. The ECG, blood pressure, and recorder modules are 
described in the articles on pages 21, 25, and 26. The system not only provides the clinician with the raw 
data measured by these modules, but also processes it, as explained in the article on page 40, to obtain 
many meaningful indicators of physiological functions, such as ventricular ejection and systemic vascu- 
lar resistance. Ease of use is delivered by a thoroughly tested user interface design (see page 29), which 
can be localized easily for most languages (page 37). Mechanical design, software testing, and produc- 
tion and final test of the Component Monitoring System are the subjects of the articles on pages 44, 49, 
and 52. 

The personal computer, or just PC, based on the Industry Standard Architecture (ISA) pioneered by the 
IBM PC, has gained steadily m processing power as each new generation of Intel microprocessors was 
introduced. The HP Vectra 486 PC uses not only the latest-generation microprocessor, the Intel486, but 
also the new Extended Industry Standard Architecture (EISA). The Intel486 integrates the CPU, a cache 
memory, and a math coprocessor onto one chip running at 25 or 33 megahertz. The EISA takes the 16-bit 
ISA bus to 32 bits while maintaining compatibility with all ISA I/O cards. The design of the HP Vectra 486 
shows that designers can still contribute creatively within the constraints of industry standards. Among 
the design contributions are an architecture that incorporates all of the new technical features of the 
EISA and adapts easily to faster versions of the Intel486, a bus connector that accommodates both EISA 
and ISA cards, a burst-mode memory controller, a high-performance hard disk subsystem, and enhance- 
ments to the Vectra's basic I/O system (BIOS) to take advantage of all of the new features. An overview 
of the Vectra 486 design appears on page 69, and the articles on pages 73, 78, and 83 discuss the con- 
nector, memory controller, and BIOS designs. Performance analysis of many of the design concepts was 
done using a specialized hardware and software toolset, allowing the designers to make critical design 
trade-offs before committing to hardware (see page 92). 
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How much does a software defect cost in terms of unnecessary expense and lost profit? Why is it impor- 
tant to know? As Jack Ward of HP's Waltham Division explains in the article on page 55. if you're trying to 
justify the cost of a new software development tool, it helps to know what the tool will save by reducing 
software defects. He proposes an algorithm for computing the cost of software defects, applies it to a 
five-year database of software product releases, and shows that defect prevention and early removal 
can save a lot of money. 

Code inspections are now standard procedure in many software development organizations. Are they 
effective? The article on page 58 describes the results of one HP division's effort to collect data to find 
out. There are both positive and negative findings, but the conclusion is that formal inspections are 
beneficial, while the value of informal inspections is still open to question. 

R.P. Dolan 
Editor 



What's Ahead 

The December issue will feature HP Sockets, a software tool for integrating applications in a network 
environment. An article from HP Laboratories in Bristol, England will introduce HP's formal specification 
language, HP-SL, and four articles will present examples of the use of HP-SL in software development. 
Another article will describe the HP Network Monitoring System for telecommunications networks using 
the 2-Mbit/s primary rate interface and the CCITT R2 or #7 signaling system. The 1991 index will also be 
included. 
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Introduction to the HP Component 
Monitoring System 



This fourth-generation patient monitoring system offers a set of hardware 
and software building blocks from which functional modules are 
assembled to tailor the system to the application and the patient. 

by Christoph Westerteicher 



Over the pasl twenty years IIP has been a supplier of 
patient monitoring equipment to the healthcare industry'. 
Palient monitors are observational and diagnostic tools 
that monitor physiological parameters of critically ill pa- 
tients. Typical parameters include (he electrocardiogram 
(ECG). blood pressure measured both invasively and non- 
invasively, pulse oximeter (SaO-i), and respiratory gases, 
among others. The catalog of parameters is still growing 
based on the need for better patient care and the techni- 
cal feasibility of new measurement techniques. 

Patient monitors are used in a variety of departments 
wilhin hospitals. These include operating rooms, intensive 
care units, cardiac care units, in-hospital and oul-of-hospi- 
lal transportation, and special (unction areas such as 
lithotripsy and x-ray. A patienl moniloring system must be 
versatile and applicable lo most of these areas. This 
means thai il must support a wide range of configurations 
and allow quick adaptation to the pal ienl -specific level of 
care. For a normal appendectomy, monitoring I he ECG, 
noninvasive blood pressure, SaO^. and one temperature 
will suffice. At (he other extreme, during a cardiovascular 
operation as many as eight different physiological parame- 
ters will be measured. 

The IIP Component Moniloring System is designed lo 
meet these requirements. This article outlines the high-lev- 
el project goals and the approaches laken lo meet them. 
It also describes the overall hardware and software archi- 
tecture of the IIP Component Moniloring Sysiem, Subse- 
quent articles in this issue highlight the technical contri- 
butions of the Component Monitoring System project in 
more detail 

Design Goals 

The IIP Component Moniloring Sysiem is Ihe fourth gen- 
eration of patienl monitors lo he designed and built by 
the HP Medical Products Group. Based on our experi- 
ence, current customer needs, and expected future trends 
in the medical field, two objectives were viewed as areas 
in which HP could make a major contribution. One is the 
area of modularity and flexibility and the other is ease of 
use. 

Modularity and Flexibility. The monitor is composed of the 
following functional modules: 
Data acquisition 
Parameter signal processing 



• Moniior control and data input 

• Display 

• System connects. 

Each of these functional modules is implemented in a set 
of hardware and software building blocks, which as a 
whole form the Component Moniloring System depicted 
in Fig. 1. Separating the moniior into its generic elements 
provides many advantages. Firsl, the moniior can easily 
be configured to best meet Ihe application needs of Ihe 
individual customer. Parameters can quickly be combined 
according to the required level of care and changed when 
necessary. Second, adding functionality to a monitor is as 
simple as inserting Ihe appropriate hardware into an ex- 
isting unit and updating the software if necessary. 



A third advantage is lhal Ihe Component Moniloring Sys- 
tem can be kept abreast of new technological trends by 




Fig. l. In the IIP Component Monitoring System, a fourth-genera- 
tion patient iniiiiitcir, each functional module is implemented i" » 
set "f hardware and software building blocks. 
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Fig. 2. The Component Monitoring System architecture lias three 
segments the module rack and parameter modules, tin- computer 

module, mui the displays The module neb can be either an Integral 
pari i.l" the computer module or totally detached. A remote keypad 
Is optional. 

enhancing or redesigning the appropriate functional ele- 
ment. Implementation will only affect one building block, 
and will be fully backward compatible with existing sys- 
tems. 

Finally, production has been dramatically simplified, ( us 
ionization of each monitor is the last integration step in 
production. Thus, all components can be assembled and 
tested without knowing Ibe specific configuration in 
which I hey will be used. 

Flexibility is enhanced by designing the monitor compo- 
nents so (hat their physical location can be Optimized (0 
address ergononnc considerations and by allowing the 
user to program (he monitor's default sellings and stan- 
dard configuration. This means lhal the monitor can be 
adapted to a wide range of current and future clinical 
applications. 

Ease of Use. Base of use is of particular Importance for 
patient monitors in operating rooms and critical care 
anils, where clinicians use palient monitors to make in- 
formed decisions about potentially life-threatening situa- 
tions. In the past, clinicians have had to strike a compro- 
mise between the desired fimelionaiity of a palienl 
monitor and its ease of use. Our goal was to make this 
very sophisticated piece of equipment truly intuitive for 
doctors and nurses lo use. Oilier areas lhal we focused 

on. and thai played an important role during die develop- 
ment phase were: 

Implementation of met hods lo meet HI' quality goals 
Minimization of production costs and support for a linear 
COSt profile. This means thai fimelionaiity can be seg- 
mented down to its generic building blocks. Should a par- 
ticular feature be needed, the customer pays for ii and 
nothing more. 

Standardization, ranging from uniform design tOOjS and 

software development environments all the way to mini- 
mizing the number of different electrical components 

used in the Component Monitoring System as well as the 

number of mechanical parts needed lo assemble ihe unit. 



System Architecture 

From an architectural standpoint the Component Monitor- 
ing System can tie divided into three segments (see Fig. 
2): 

• Module rack with parameter modules 

• Computer module 

• Displays. 

The module rack and parameter modules represent the 
interface to the patient. Each parameter module Ls dedi- 
cated to the measurement of one or more physiological 
signals, and is housed in a separate enclosure. Within the 
parameter modules, the transducer signals are electrically 
isolated from ground potential, amplified, sampled, and 
converted from an analog to a digital format. The digital 
parameter values together with the status of each module 
are polled at fixed intervals and sent to the computer 
module for further Interpretation. 

Up to eight single-width modules fit into one module 
rack. The module rack can be either an integral pari of 
the computer module or totally detached, in which case it 
would be called a satellite module rack. The satellite 
module rack is connected to the computer module by an 
unibilical-cord-like cable, which carries both the digital 
signals and a 80V dc power line for Ihe parameter mod- 
ules. One computer module can support as many as four 
satellite module racks. This concept allows the user to 
position the parameter modules as close as possible to 
the patient, where the signal is measured. The transducer 
cables Can thus be kept short, minimizing the amount of 
wiring as well as the tendency for it to become tangled 
or draped over the patient. 

Computer Module 

The computer module is the main processing unit. It con- 
sists of a cardcage that can house up to 2-i function 
cards and one dc-to-dc converter (Fig. :i). Function cards 
currently available include CPUs, memory cards, interface 
cards, display controllers, and a utility card. For Ihe lii>:l 
release, a total Of H (unction cards were designed. The 
interconneclion within Ihe cardcage lakes place via the 

central plane, a motherboard located In the middle of the 
chassis with press-fit connectors mounted on both sides 




Fig. 3. The computer module houses up lo 2:1 function cards 
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Fig. 4. Functional block diagram nf a Component Monitoring Sys- 
tem palient monitor. The shaded boxes are software functions on 
the CPU card processors. The solid boxes are specific hardware and 
firmware functions. 



of a printed circuit board. Data exchange between the 
function cards takes place on the message passing bus. 
This bus is routed to all 23 slots on the central plane, 
allowing a high degree of freedom as to where a function 
card can be inserted. The message passing bus is the 
backbone of the Component Monitoring System. Many of 
the goals listed above only became possible with the help 
of this communication concept. 

The basic function of the message passing bus is that of 
a broadcast system. Each message sent on the bus con- 
sists of a header, which describes the content, and the 
actual data. A source (e.g., a CPU card) will obtain con- 
trol of the message passing bus and transmit its informa- 
tion. The data is not transmitted in a point-to-point fash- 
ion from one source to one receiver. Instead, message 
passing bus data is transmitted without any specific desti- 
nation, and it is up to the function cards to watch for the 
information needed by their applications. As soon as a 
card detects a match between a header it is looking for 
and the header of the message on the bus, it automatical- 
ly pulls this data into an internal stack. 

The activities of bus arbitration, transmission, header 
matching, and data reception are controlled by the mes- 
sage passing bus chip. One of these interface chips is 
located on each function card that actively takes pan in 
the communication process. The chip was designed spe- 
cifically for the Component Monitoring System. It also 
was the first HP production ASIC (application-specific IC) 
to be designed using a silicon compiler tool. 

A more detailed description of the message passing bus 
concept and the design of the interface chip can be found 
in the article on page 10. which covers the Component 
Monitoring System hardware architecture. 



Displays 

The customer can choose either a monochrome or color 
high-resolution display. Multiple independent displays can 
be used to present different sets of information to specif- 
ic user groups. For example, the surgeon needs a differ- 
ent presentation of patient information than the anesthe- 
siologist fluring surgery. 

Physically separating the display from the computer mod- 
ule gives the user a choice of screen sizes and the possi- 
bility of mounting the computer module at a remote loca- 
tion when space next to the patient is at a premium. 

The user interacts with the monitor through a combina- 
tion of hardkeys and softkeys on the display keypad or 
through a remote keypad which functionally duplicates 
the keys on the display bezel. 

Software Modularity 

The concept of a modular system also applies to the soft- 
ware architecture (see Fig. 4). Application-specific mod- 
ules represent the basic building blocks out of which the 
total solution can be assembled. The ECG application, for 
example, including the signal interpretation, alarm han- 
dling, and control interaction, is all encapsulated in one 
module. To the surrounding environment these application 
software modules are totally self-contained packages, and 
only exchange information with one another via the mes- 
sage passing bus. By virtue of this concept, it is possible 
to link each module as an independent entity with any of 
the other modules and assign it to one of the Component 
Monitoring System CPU cards. 

A more detailed description of the software architecture 
can be found in the article on page 13. 

All of the Component Monitoring System software is 
stored on EPROM function cards. These cards are physi- 
cally located next to a CPU, and the applications running 
on that CPU execute directly from the adjacent memory 
card. All other CPU cards in the monitor get their appli- 
cation software downloaded into the on board RAM dur- 
ing boot time. The advantage of this solution is that in- 
stalling software is as easy as inserting one EPROM card. 

Summary 

The Component Monitoring System has proved that the 
concept of component modularity can be extended far 
beyond the mere ability to mix and match parameter 
modules. Modularity in this system means that the cus- 
tomer can tailor the patient monitor to best fit the appli- 
cation all the way from the parameters that need to be 
registered to the displays and interfaces the system 
should incorporate. The Component Monitoring System 
can also grow with the user's needs over time, and thus 
secure the hospital's assets for many years. 

The success of the modularity concept is reflected in the 
fact that some of the hardware and software elements 
have found their way into other medical devices manufac- 
tured by HP. Overall, the Component Monitoring System 
architecture has proven it can function as a monitoring 
platform for years to come. 

Icominued on page 101 
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Medical Expectations of Today's Patient Monitors 



HP has been a supplier of patient monitors since the mid- 1 960s The HP 7830. HP , 
782xx. HP 7835x. and HP 7853x monitors have measureo vital signs lite ECG. blood 
pressure, body temperature, carbon dioxide, inspired oxygen, and others 

Over the years, customer demands and measurement technology have both devel- 
oped Simple ECG monitors have gradually oecome complex monitoring solutions, 
acquiring, processing, displaying, and storing many parameters These modern 
monitois need to communicate over dedicated LANs, both with one another and 
with central stations For this purpose, several years ago. HP introduced a serial 
distribution network (SON), which makes it possible to transmit a multitude of 
parameters, high-resolution waveforms, and other information to as many as 32 
participants in a synchronous way These features are not easily achievable with 
modern asynchronous LANs 

Medical Expectations 

Most of today's patient monitors do not satisfactorily fulfill many of the current 
and future expectations for these systems The increasing need to measure new 
parameters and to postpiocess this information using powerful signal processing 
algorithms and data management tools require a different approach At the same 
time, our customers are under tremendous cost containment pressure, allowing 
them to invest in new equipment only in cycles of seven to fifteen years Having 
these and other customer needs in mind, we launched a development program foi 
a new patient monitoring system The goals of our project were to. 
Develcp a solution that can be easily adapted to our worldwide customers' medi- 
cal as well as financial needs 

Develop a user interface that allows the user to control the system easily through 
different means including softkeys, touch, and remote keyboards (see article, page 
29) 

Develop a solution for all maior languages, including Asian languages 

Develop a solution that is backwards compatible with the existing LAN ISDNI and 

luture LAN implementations 

Develop a solution corresponding to our customers' space restrictions This often 
means acquiring measurement data close to the patient to avoid the so-called 
"spaghetti syndrome"— too many cables around the patient — and processing 
and displaying the measurement data farther away from the patient, 



Develop a solution that allows additional CPUs to be added to the system accord- 
ing to die signal processing needs, and that provides independent displays that 
can be addressed directly 

Conclusion 

The HP Component Monitoring System is our solution to these needs Fig 1 shows 
the bedside monitoring concept of this system Expansion is possible both horizon- 
tally and vertically in this matrix The horizontal axis shows trie various functional 
needs, while the vertical axis shows various ways in which these needs are met ki 
specific applications The last row of the matrix shows examples of possible future 
capabilities that can be added easily to the Component Monitoring System if and 
when they oecome available 

The HP Component Monitoring System is an ultraflexible patient monitoring sys- 
tem that can be adapted to almost all monitoring needs that arise in hospitals 
worldwide. Its built-in modularity and an HP proprietary message passing bus 
make it independent of technology changes m microprocessors, LANs, or displays 
This is expected to result in a very long product lifetime, thereby protecting our 
customers' investments. By affenng different configurations of the Component 
Monitoring System, we provide a wide pi ice/performance range, and through a 
flexible upgrade strategy, we ensure high adaptability to our customers' future 
needs. 

The Component Monitoring System is a truly international development that in- 
volved engineers in the U S A and in Europe Today, it is being manufactured at 
two HP sites, one in Europe and one in the U.S.A. 

Such a significant technology step can never be taken without encountering chal- 
lenges Thanks to the engagement and dedication of all of the team members, 
these challenges were met successfully 

Frank Rochliuer 
General Manage! 

Surgical and Neonatal Caie Business Unit 
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Component Monitoring System 
Hardware Architecture 

Up to 23 function cards residing in a computer module communicate over a 
message passing bus. The computer module, the display, and the 
parameter modules that measure vital signs can be in separate locations 
as needed by the application. 

by Christoph Westerteicher and Werner E. Heim 



The prime objective in the development of the 111' Com- 
ponent Monitoring System was to build a patient monitor 
that would adapt optimally to the majority of clinical 
applications, now and in the foreseeable future. To the 
R&D team, this meant modularity, but not just in the 
sense of being able to mix and match parameters, The 
goal of this project was to carry the idea of configurabil- 
ity a quantum leap into the future. 

Major Parts 

The Component Monitoring System can be segmented into 
three parts (Fig. 1): 

• The rack and parameter modules 

• The computer module 

• The display. 

This segmentation is not just a theoretical way of looking 
at the Component Monitoring System. The system can 
actually be separated into these components. It is there- 
fore possible to place the parameter modules close to the 
patient and position the display within sight of the anes- 
thesiologist, while the computer module can be totally 
removed from the vicinity of the patient. 

Computer Module 

The computer module incorporates all the processing 
power, the interfaces to other devices and networks, the 
display controllers, and drivers for human interface equip- 
ment . 

These functional elements have been broken into their 
generic components, and then designed and implemented 
as individual function cards. The processing power, for 



example, is provided by an application dependent number 
of CPU cards, working together as a loosely coupled mul- 
tiprocessor system. Based upon a llj/32-bil microproces- 
sor, each CPU card is an independent subsystem, includ- 
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ing a large amount of static memory, boot EPROM. and 
an interface chip for the computer module's internal bus, 
the message passing bus (Fig. 2). The ability to work as a 
sell contained, independent entity was the smallest com- 
mon denominator we wanted to apply to our computet 
module building blocks. Because of this concept, process- 
ing power, interface cards, or display controllers can be 
added depending upon the customer's application. New 
function cards can be added by plugging them into the 
computer module without interfering with the existing 
configuration. 

Local resouiees of a function card, like static memory or 
EPROM, can be extended by adding a battery-buffered 
sialic RAM card and an EPROM card. They connect to a 
local extension bus, which is routed on the same connec- 
tor as the message passing bus, thus allowing an Identical 
design for all slots on I he backplane. 

At first release of the Component Monitoring System, 
there are II (Unction cards. The spectrum includes the 
above-mentioned processor anil memory cards, interface 
cards to RS-2M2 devices and Ill's medical signal distribu- 
tion network (SDN), high-resolution monochrome and 
color display controllers, and other cards. 

Each function had to 111 onto the standard function card. 
To make this possible, several application-specific inte- 
grated circuits (ASICs) provide high performance in a 
minimum of card space. Surface mount technology allows 
components in very' small packages to be mounted c lose 
together directly on the surface of a function card. The 
benefits of these new technologies are highly automated 
production processes, reduced part count, and increased 
reliability. 

Message Passing Bus 

The message passing bus represents the backbone of Ihe 
Component Monitoring System. Il is by virtue of Ihis so- 
lution thai il was feasible to implement modularity in 

such an extensive fashion. 

The message passing bus is based on a message broad- 
casting system, in which one bus parlicipanl transmits 
Information without having to specify the address of the 



receiving device. Instead, every message is classified by a 
header, indicating the content of the message. A bus par- 
ticipant interested in a specific class of messages writes 
the header of the information and a priority into the sig- 
nature RAM of its message passing bus interface. When 
the header of the message on the bus and the header in 
the signature RAM match, the receiving card's message 
passing bus interface automatically loads that message 
into its FIFO buffer. Depending on the priority assigned, 
the incoming information is pushed into either Ihe 
high-priority or the low-priority FIFO, thereby preprocess- 
ing data for the CPU. Comparing headers and moving 
information into and out of the FIFOs is controlled by the 
message passing bus interface Chip with no interaction 
front tile data processing device. Fig. 3 is a block diagram 
of this chip. 

Th* major advantages of Ihis concept are threefold. First, 
messages only need to be senl once, regardless of Ihe 
number of bus participants interested in the informal ion. 
This guarantees thai bus bandwidth is not used merely to 
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duplicate messages going to multiple receivers. Second, 
the absolute bus bandwidth Is defined by the speed of the 
message passing bus interface chip. The chip controls the 
transmit and receive FIFOs and compares headers with- 
out support from the data processing device. In essence, 
the message passing bus chip is a buffer between a 
high-speed bus and data processing logic working at vary- 
ing speeds, which should not be Interrupted by every bus 
activity if it is to function effectively. 

The third major advantage of the message passing con- 
cept is that new system cards can be added to a monitor, 
and as long as they know the algorithm for allocating 
headers; they can actively participate on the message 
passing bus. The bus has a decentralized arbitration algo- 
rithm, which determines how each participant accesses 
the bus. Each interface chip incorporates arbitration Cir- 
cuitry based on a round-robin-like system, assigning the 
bus on a rotating priority basis. If the current bus master 
is level n, priority u - 1 will be given to the next interface 
requesting the bus, and so on sequentially. This guaran- 
tees that the bus is shared equally among all of the func- 
tion cards and is dynamically distributed every time a 
message is sent. 

The message passing bus chip was designed as an ASK '. 
using a silicon compiler tool to develop and simulate the 
circuit's functionality. 

Central Plane and Power Concept 

In the center of the computer module chassis is a 23-con- 
nector motherboard with press-fit sockets mounted on 
both the front and the rear. The message passing bus is 
routed to all 23 slots on this central plane (Fig. 4). 

Since all of the function cards are mechanically identical 
in size, any card can be inserted into any slot of the cen- 
tral plane, thus making possible a wide range of configu- 
rations. The only exemption is the dc-to-dc converter, 
which always is located in the same slot. This one Card 
provides the power for the computer module, and is 
sourced with 60V directly from the Component Monitoring 
System display (Fig. 5). 

This somewhat uncommon power architecture was neces- 
sary to comply with the stringent leakage current limits 
imposed on medical equipment. If the Component Moni- 
toring System were to incorporate separate power sup- 
plies in the display and the computer module, the leakage 
currents of both to ground would be added together, mak- 
ing it very difficult to reduce this value to below 100 uA. 
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Fig. 5. Power concept . The sm«|.- power supply is housed in the 
di.spla\ 

The second reason for taking the power supply out of the 
computer module was the need lo reduce the amount of 
heat dissipated in this small box to a minimum, so as not 
to jeopardize reliability. We therefore decided to have 
only one power supply for the entire Component Monitor- 
ing System, and to house this in the display. 

The Display 

Customers can choose either a monochrome or color 
14-inch display (Fig. (3). These are high -resolution, nonin- 
terlacing, high-contrast displays designed and built specifi- 
cally for medical applications. 

To provide outstanding waveform quality, lite displays and 
(he display controllers have a very high horizontal resolu- 
tion of 2048 pixels. At this pixel spacing the human eye 
can no longer resolve the individual dots, so the curves 
appear very smooth. 

The displays also incorporate the Component Monitoring 
System control panel, located beneath the screen. This 
control panel is the main means of interacting with the 
monitor. It consists of a membrane keyboard, LED indica- 




Fig. 4. Computer module central plane and function cards. 



Fig. 6. The display also incorporates the control panel. 
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tors, and the human interface board, which is an HP-HE. 
device looped through to the computer module. 

Summary 

The hardware architec ture has proven to be one of the 
steps OH the ladder to success of the Component Monitor- 
ing System. With the advent of this new monitor, produc- 
tion has been automated and streamlined to an extent 
unheard of for such a complex device as a patient moni 
tor. The parts standardization effort has resulted in a 
mere :MX) different items for the entire system. Our cus- 



tomers can now have a state-of-lhe-art monitoring system 
that they can configure to their specific needs, and at the 
same time be assured that their system has been de- 
signed to stay abreast with technological or application 
changes for many years to come. 
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Component Monitoring System 
Software Architecture 

A modular design leads to a complex but easily manageable system that 
ensures economical resource utilization. 

by Martin Reiche 



HP Component Monitoring System palienl modules can be 
mixed and matched to snii the application. A module is 
added simply by plugging it into any free slol in the mod- 
ule rack. Wouldn'l il be convenienl to handle all functions 
implenienleil as software the same way? Just find a free 
resource on any CPU card and assign the required sel of 
software building blocks to il. I'se only as many ('Pi's as 
necessary. This article will show that this approach is not 
only viable, but also appropriate in terms of both develop- 
ment economics and resource utilization. 

The basic idea of having building blocks wilh standard- 
ized interfaces thai can be ;irhilranly combined has prov- 
en ils power in many projects. The Component Monitor- 
ing System patient signal acquisition system, computer 
module, and message passing bus concept reflect this 
idea well. 

This approach should also be promising for software. 
However, a problem with software is its complexity, both 
internally and in terms of interaction with external enti- 
ties. Component Monitoring System software modules 
show significantly different profiles in resource require- 
ments, must share a multiprocessor real-time system in 
varying configurations without conflicts, have to act and 
communicate in a meaningful way with regard to the ear- 
rent configuration, and arc implemented by different peo- 
ple in different places at different limes. Tins makes stan- 
dardization difficult . 



We will show how Ihese problems were overcome, both 
from an arc hitectural point of view and from a develop- 
ment environment perspective. As we proceed, we will 
encounter a continuously recurring question in different 
contexts: HOW can we provide the needed creative Ere©- 
doin for each individual, and at the same lime manage 
their cooperation and Integration into a coherent total 
solution? 

Layered Software 

As can be seen in Fig. 1. the Component Monitoring Sys- 
tem's functionality can be represented in a layered 
scheme. Similar to exisling computer systems, the hierar 
chy has four levels: 
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Fig. I. Th'' basic task allocation scheme of the Component Monitor- 
ing System uses ,i layered software si met tire The lower-layer activi- 
ties are transparent to the application software modules, which are 

designed lo run on a virtual processor. 
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Component Monitoring System 
Software 



Total amount of source code 31 5 KNCSS 

Number ol software modules developed 30 

Number of mudule instances In an instrument 43 

Number of message passing bus headers allocated 

by the operating system B80 

Average data flow on the message passing bus 50 kbytes/s 



The CPl" raids represent the hasis for all data process- 
ing. They communicate over the message passing litis. All 
interfaces to external devices are found here. 
Firmware located on these cards provides services to the 
higher layers of the model. The firmware implements 
complex application independent functions by conven- 
ing commands and protocols inlo hardware related sig- 
nals. Patient parameter modules play a special role: con- 
trolled by firmware, their analog and digital hardware 
converts the incoming patient signals into digital infor- 
mal i<m accepted by the computer module. 
The operating system establishes the data paths between 
the application software modules on the one hand and 
the firmware on the other. It controls the execution of the 
application programs, moves messages back and forth, 
and continuously supervises the correct execution of all 
Fund ions. 

It is up to the applications to provide the signal interpre- 
tation, computation, alarm generation, and similar func- 
tions and to support user interaction by drawing windows 
and menus on the screen. How functions are implem- 
ented In the lower layers is hidden from the application 
software modules. 

Modules and Messages 

All function cards are designed so that they can be arbi- 
trarily combined over the central plane. They can trans- 
mit and receive messages and perform their functions 
regardless of the slots in which they reside. 

In a straightforward extension of this principle, the Com- 
ponent Monitoring System software architecture allows 
for arbitrary distribution of software to the various pro- 
cessor cards (see Fig. 2), These self-contained application 
software modules are the building blocks of the modular 
system. Each module represents a large functional area — 
for example, the signal processing for the blood pressure 
measurement with its affiliated aspects of alarming, con- 
trol interaction, transducer calibration, and so on. 

To achieve this modularity, the current configuration is 
made transparent to the modules. They will execute on 
any CPU card, and their sharing of a CPl' card with oth- 
er modules will not interfere with their operation. The 
only way they can communicate Ls to transmit and re- 
ceive messages. As with the message passing bus, the 
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origins and destinations of these messages are hidden 
from the application. 

This principle guarantees maximum flexibility in reaching 
the required functionality with a given hardware set. Ii 
also reduces development risks, since at the beginning of 
a complex project, neither the sizes of the modules nor 
the resulting processing requirements can be accurately 
estimated. 

Inside a Module 

From a programmer's point of view, a module is com- 
posed of a number of related C-language source files (see 
Fig. 3). There are different types of files. For example, 
PROG files contain executable code and variable defini- 
tions, and TEXT files consist only of character codes. 

Following a tailored syntax, an ASCII file called a module 
table provides comprehensive information about that mod- 
ule. Identification, communication behavior, execution, 
and resource requirements are specified in this table. Tliis 
file is converted to C source code by means of an IlP-de- 
veloped compiler called mtc. In this way. a generic module 
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Fig. 3. An application software module consists of a module table 
and a set Of C source files. A proprietary Compiler, mtc. converts the 
module table to C source code. 
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structure is defined, along with a formal description of 
interfaces among the modules and the rest of the system. 
These standardization rules are followed by every soft- 
ware designer, specify the guidelines for all interaction, 
and lay the foundation for a fully automated code genera- 
tion process. Thus, machine-processed specification en- 
fortes standardization- 
All C code is then compiled and linked, yielding a num- 
ber of object files, which are loaded unchanged into an 
EF'ROM card to be plugged into the computer module. 

Virtual Processor 

The main characteristic- of this software concept is thai 
the current configuration is invisible to all of fee applica- 
tions. They do not know which modules are assigned to 
which processor, how many processors are available, 
which Interface cards are present, or where messages 
come from and where they go. Therefore, software devel- 
opers must not make any assumptions as to where their 
applications will be executed. The only way modules are 
allowed bp communicate with each other is by exchanging 
messages. 

These are prerequisites for a truly modular system in 
which applications can be mixed and matched according 
(0 a predefined functionality. Willi this in mind, it is ap- 
propriate to define an abstract programming model that 
we call a virtual processor (see Fig. I). This is a collec- 
tion of artificial resources such as application priorities or 
data links. The virtual processor supplies the application 
programmer with all of the construction elements neces- 
sary to implement functions effectively and straightfor- 
wardly. The programmer can write functions that process 
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Fig. 4. Execution trees can be started after a certain amount of 
lime has elapsed or when a certain evenl occurs. 



Component Monitoring System 
Software Development Environment 



All development was performed on HP 9000 workstations running under the HP-UX 
operating system and connected By a local area network This includes the operat 
inq system, the development loots, and alt applications and doaimemation Each 
workstation red mass storage and emulation facilities IHP 6*000) and could be 
tailored to specif* needs 

Starting out with only a few developers on a single HP 9000 Series 500. we ended 
up with about ten HP 9000 Series 300 systems being used by 20 software engi- 
neers toward the end of the project 

Thanks to the power and flexibility of ihese HP-UX systems, the continuous evolu- 
tion of the development environment proceeded very smoothly with respect to 
both its extent and its compreliensiveness. For example, all genenc data (e.g., 
symbol tables for message specification or tools for process automation! was 
automatically updated on all machines As a consequence, at any point in time, 
identical processes were used pioiect-wide— a prerequisite for smooth integration 
of the components 

Since all application modules have the same form, it was possible to implement 
the standard generation processes only once. Besides the definition and evalua- 
tion of the module lable, a uniform process supports the implementation of any 
application This turned out to be very helpful, for despite the different functions of 
Ihe modules and tfie various inclinations of the development engineers, one al 
ways finds recurring features in arty implementation This makes software mainte- 
nance easier for engineers other than the original programmer For example, differ- 
ent language options of a module can he generated without touching any code 

In our environment, a single engineer had complete responsibility for specifying, 
designing, and implementing each software module The activities of all of the 
developers had to lie decoupled as much as possible Since enforced synchronisa- 
tion would have been intolerable, a major requirement for the development envi- 
ronment was to suppott easy generation of running versions at all involved work 
stations Here the Component Monitoring System's self-configuration, 
implemented as the boot process, proved valuable All software modules are 
sell-contained and independent During the boot process the modules are initiated 
within the current run time environment This environment can always be tailored 
to meet the needs of the module under consiructiun 

The integration process is always exer.uteri ihe same way The current versions of 
Ihe operating system and uthei modules are collected from the workstations on 
ihe IAN and are loaded into the current woik environment A configuration lalile 
then assigns the modules to CPUs in such a way that each module under construc- 
tion runs on an emulated CPU Symbol tables can ihen be corrected lielorehand lu 
allow for symbolic access to all variables and functions. 

In summary, the extensive effort invested ill the development environment and 
buot process has been very beneficial to the entire development and maintenance 
process, as well as to the produci's quality Other proiects leveraging from the 
Component Monitoring System platform have profiled and will continue to profit 
from tins comprehensive and comfortable development environment 



messages without having to pay attention to how the in- 
formation is ilistriliulcil. Concepts such as iiilcnupts. Ia.sk 
control Mucks, and Ihe message passing bus chip can be 

ignored by ihe programmer, who is Tree to concentrate mi 

Ihe medical application. Thus, the application program- 
mers task is to convert Ihe specific functions into pro- 
grams that can run on the virtual processor, and the Oper- 
ating system's task is to support Ihis program module by 
means of the Current hardware configuration and ensure 
thai any two applications on a single GPU do no! inter- 
fere with each other. 
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The features of the virtual processor are defined very 
formally, and the application programmer can only build 
on litem. The interface specification of a module with 
respect to the virtual processor is found in the module 
table and is expressed in terms of the virtual processor. 

This abstract model and its formal presentation have 
proven to be extremely useful, both for separating tasks 
within the development process, and for automating the 
integration process. 

Execution Model 

Every module's program code can be considered a set of 
routines forming separate execution trees. The entry rou- 
tines, that is, the roots of tbe trees, can be executed after 
the completion of a certain time period or upon reception 
of a message (Fig. 4). Since functional areas within a 
module may have different precedence requirements, ex- 
ecution trees can be assigned to one of several applica- 
tion priorities (see Fig. 5). For example, continuous was - e- 
fonn processing has the highest priority assignable, 
because it must process a batch of samples every 32 ms, 
and thus may delay the execution of all other functions if 
given a lower priority. 

The lotal computing capacity of a certain CPU may be 
distributed among several execution trees within several 
modules with several priorities. The overhead generated 
for context switching is minimal. 
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Fig. 5. Application module software can be thought of as a set of 
execution trees. These are assigned to application priorities, which 
are Virtual processor resources. 
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The application programmer specifies the priority of each 
execution tree. At run time, the execution time is parti- 
tioned externally to the module, without effecting its 
functionality. The programmer also specifies the amount 
of execution lime required. The operating system guaran- 
tees every application the timely execution of each tree 
and checks this in a continuous fashion. This is essential 
to the safety of patient monitoring. 

Communication Model 

As already mentioned, communication among software 
modules and interface cards is implemented as an ex- 
change of messages. Message routing functions reference 
a 12-bit header, allowing for a maximum of 4096 different 
data streams. It would have been possible to assign all 
headers project-wide in advance, but the Component Mon- 
itoring System employs a more elaborate process for es- 
tablishing data paths. Every message has a composite 
(six-field) symbolic identification assigned. This is eval- 
uated at boot time when headers are allocated I see Fig. 
(i). Modules transmitting or receiving messages specify 
this symbolic identification within their module tables. 
This method allows the implementation of some impor- 
tant concepts. If modules are installed more than once, 
say for multiple pressure lines, multiple similar data paths 
have lo be established appropriately. This can be done 
externally to the modules at boot time simply by counting 
the source numbers shown in Fig. (i. Also, related mes- 
sages can be collected into message classes by assigning 
identical keys, for example to the type field. Each mes- 
sage of a specific class then shares a predefined struc- 
ture. 

Programming with message classes represents a powerful 
method for dealing with configuration dependencies. The 
operating system supports broadcast messaging in a very 
convenient way. For example, all alarm messages gener- 
ated by various sources are transmitted in messages of 
type ALARM The central alarm management facility — an 
application software module — can specify that it wants to 
receive all alarm messages and then process them in the 
order that they appear. Using wild-card specifiers for the 
unknown fields in the symbolic identification keeps the 
module code receiving broadcast messages regardless of 
the current configuration. Blocks of memory for class 
members can be requested with a simple entry in the 
module table. The configuration dependencies are then 
resolved at boot time. 

Besides broadcasting, the Component Monitoring System 
operating system uses two other important types of com- 
munication: static point-to-point and dynamic point-to- 
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point. Static links are private communication links be 
tween two entities, most notably application software 
modules and interface cards. Dynamic links are valuable 
when one resource is used by different application soft- 
ware modules at different times. A temporary write to a 
screen area or the reading of soft keys are examples of 
this concept. Classes of dynamic link nodes can be de- 
fined using the mechanism described above (link nodes 
are entry points into an application software module 
whose affiliated message is of some type specified in the 
receiver's module table). Fig. 7 summarizes how these 
conununication types are built on the message passing 
bus broadcast facility to serve the upper application level. 

The standard parameter interface represents the backbone 
of patient data communication within the Component 
Monitoring System. It is a set of class definitions that 
forms a kind of logical data bus on which all patient data 
processing modules can broadcast their data. Any receiv- 
er can then operate on waveform, numeric, alarm, or Oth- 
er messages in a completely decoupled fashion. 

Automated Configuration 

Modules Contribute to the system's flexibility only if their 
handling is simple, comparable to the ease of handling 
patient parameter modules. To achieve this, the Compo- 
nent Monitoring System development environment makes 
heavy use of automated processes, acting on formal inter- 
face descriptions. The module table, for example, is com- 
posed of the formal specifications relating to the specific 
module. When specifying communication behavior and 
execution requirements, the programmer can reference 
items of interest by means of symbolic names — the same 
names that can be found in the program source code. 

As long as the system is not powered, all hardware and 
software components appear unrelated. The computer 
module cards are all connected electrically, but no logical 
data path is apparent. The CPUs are "empty" (Fig. 8a). At 
boot, a monitor configuration table located on the central 
EEPHOM tells the boot process how to arrange software 
modules on the CPU cards (Fig. 8b). Using the module 
tables in the individual modules, the boot process binds 
the modules into the run-time system. After the program 
code has been transferred to the CPU cards and all con- 
figuration dependent data structures have been initialized, 
all modules will operate as expected. More than 10 appli- 
cation software module instances are installed in the 
Component Monitoring System. 



In this process, the module tables supply all information 
necessary to install the data paths. In the first step, reser- 
vations for message passing bus headers are accepted. All 
references to communication concepts such as message 
classes can then be resolved. The process is analogous to 
the link process for computer object code. More than 800 
message passing bus headers are allocated by the boot 
process; this gives an idea of the amount of communica 
lion that is required to operate the system. 

Delaying the linking of software modules until the boot 
process has, among others, one important advantage: it 
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allows ronflguration independent implementation and an 
ease of software maintenance thai is normally true only 
of hardware elements. 

Conclusion 

Both the software design and the Component Monitoring 
System software development environment (see page 15) 
placed great emphasis on decentralization and decoupling 
and on the standardization and formalization of interfaces. 
The latter provides the opportunity for comprehensive 
automation, which in I urn shows significant advantages: 
Automation of all external activities supports a smooth 
integration of each module into the total solution. It elimi- 
nates communication problems within the development 
team l>y separating responsibilities and establishing non- 
corruptible entities. 

Automated processes are reliable and efficient. They only 
have to be implemented once, and future users do not 
need an in-depth understanding to be able to use I hem. 
Automated processes enforce consistency. Deviations 
from a standard are prevented by the tools. Specification 



flaws quickly become apparent. The overall system re- 
mains consistent . This is an important contribution to 
software quality. 
• Automated processes maintain flexibility. The evolution 
of processes can be coordinated centrally, with only a 
few engineers involved. Users are affected to a much 
lesser degree. 

A project of the magnitude of the Component Monitoring 
System software development cannot be managed in a 
reasonable way without a very high degree of automat ion. 
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Component Monitoring System 
Parameter Module Interface 



This interface is the link between the component Monitoring System 
computer module and the patient parameter modules. It provides fast 
response, optimum use of the available bandwidth, configuration 
detection, and parameter module synchronization. 



by Winfried Kaiser 



The parameter module interface of the IIP Component 
Monitoring System is the interconnection between the 
computer module and the module rack. The module rack 
can house a wide range and a varying number of parame- 
ter modules. By means of transducers attached to the 
patient, the parameter modules measure the patient's vital 
signs. These devices include the ECO, temperature, and 
recorder modules, and many others. 

The major challenges associated with the design of the 
parameter module interface can be summarized as fol- 
lows: 

The system mast be able to support communication be- 
tween the rack interface card in the computer module 
and a variety of parameter modules thai may differ in 
such Characteristics as the sampling rate of the analog 
signal, the number of signal input or output channels, the 
kind and amount of data thai a parameter module re- 
CelveS from the computer module (control data) or sends 
tO the computer module (stains data), and mechanical 
size (1,2, or 3 slots wide). 



• It is a requirement of some clinical applications thai cer- 
tain waveform samples be measured and made available 
at an analog output with an absolute delay of less than 20 
milliseconds. 

• It must be possible to plug any parameter module into 
any slot in the module rack. The system must identify the 
parameter module and ftS position within the rack (con- 
figuration detection). 

• The communication link of a system under power must 
not be influenced by plugging in or unplugging parameter 
modules or even entire racks. 

. The parameter modules must be synchronized with each 
other. 

. The link musl support the detection of defeclive devices. 
Link Design 

The rack interface card in the computer module has one 
connector to interface to as many as four module racks. 
A module rack houses a maximum of eight single-width 
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modules. This means thai up to 32 parameter modules 
ran he attached to one rack interface card. 

Connections are established to each of the 32 slots by 
means of five address lines (sec Fig. 1). Using these ad- 
dress lines, the decoding logic in the addressed module 
rack connects one of that rack's slots to the receive and 
transmit lines of the rack interface in the computer mod- 
ule. 

The serial interface of the 80C51 microcomputer (internal 
I 'ART, full duplex. 51)(>-kbaud) is used for communication 
between the rack interface card and the addressed param- 
eter module. Because of the fast response time require- 
ment, il was decided that the parameter modules should 
transmit their information one sample at a time. The rack 
interface gathers all parameter samples over a period of 
32 ms and forms them into the corresponding message 
passing bus data 

Communication Protocol 

The rack interface controller starts the communication 
with the parameter modules with a special identification 
cycle. All possible rack slots are addressed, and a special 
control byte requests identification. A connected module 
responds by sending its device identification, hardware 
and firmware revision, and other parameter-specific data. 

Using this identification and an internal reference table, 
the rack interface compiles a!! necessary data about the 
connected device types. This includes each device's sam- 
pling rate and its number and kind of transmit and re- 
ceive bytes. After scanning all of the slots, the system 
knows which parameter modules are available. 

Special digital logic together with a simple connected/ 
not-connected connector pin inside each parameter mod- 
ule enables the rack interface to recognize whether or 
not a module is plugged into any slot, or whether a mod- 
ule is defective. If a parameter module is connected, it 
responds when it receives the control byte from the rack 
interface. If a module is not connected, the incoming byte 
is sent back to the rack interface card without any delay. 
If there is no response at all a defective module is recog- 
nized. 

Scan Table 

Alter the system determines which parameter modules 
are present, a scan table is generated in the rack inter- 



face to describe and control all subsequent communica- 
tion. The scan table consists of 16 2-ms time slices. The 
table entry for each time slice specifies which parameters 
are polled during that time slice (see Fig. 2). 

The arrangement of the scan table depends on the speed 
classes of the parameter modules connected. There are 
five speed classes based on the sampling rale of the pa- 
rameter modules: 2-ms, 4-ms, 8-ms, 16-rns, and 32-ms. The 
2-ms parameters are entered in each column of the scan 
table, the 4-ms parameters in every other column, and so 
on. A special algorithm guarantees that the entries are 
made so that each device is addressed at fixed intervals. 

The free part of the scan table is used to address slots 
that have no modules inserted. When a parameter module 
is plugged into the rack it is immediately recognized and 
activated in the scan table, which contains the superset 
of all parameter modules that are allowed. A module that 
is removed froin the rack is deactivated. Thus it is possi- 
ble to connect and disconnect any parameter module dur- 
ing normal monitoring. 

Analog output devices that need a fast response time are 
entered at the end of each lime slice and receive the data 
from the selected parameter module within the same lime 
slice. The total delay from input to output is less than 2 
ms (see Fig. 2). 

Parameter Module Interaction 

When a parameter module is addressed by sending it a 
message (receive interrupt), it responds immediately by 
transmitting a predefined internal data block, typically 
consisting of waveform and status data. After the trans- 
mission, the parameter module starts an analog ! o-digital 
conversion cycle of the patient signal or performs other 
tasks depending on the control information in the re- 
ceived message. The result of the analog-to-digilal conver- 
sion and status information are stored into a module's 
internal data block. This data is transmitted the next time 
the parameter module is addressed. Since communication 
with a particular device always takes place after a fixed 
interval, the module can synchronize itself with this poll- 
ing sequence. 

At the 500-kbaud data rate of the parameter module inter- 
face, a typical communication cycle with a parameter 
module with one waveform takes about 121) microsec- 
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onds. When communication with one module has been 
completed, the next device in the scan table is addressed. 

This procedure ensures both optimum use of the available 
bandwidth and synchronization of the parameter module 
and the rack interface card. 

Summary 

The parameter module interface represents a very flexible 
solution for connecting a wide variety of modules to the 
Component Monitoring System computer module. Al- 



though the requirements addressed by the interface are 
complex, the final implementation is both versatile and 
rugged, and was kept relatively simple by integrating 
some or the decoding logic. 
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Measuring the ECG Signal with a 
Mixed Analog-Digital 
Application-Specific IC 

Putting the ECG data acquisition subsystem into a Component Monitoring 
System parameter module mandates high-density packaging and low 
power consumption, and was only possible by implementing major 
elements of the circuit in a large mixed analog-digital ASIC. 

by Wolfgang Grossbach 



Nearly everyone is familiar with one of the most impor- 
tant medical parameters— the electrocardiogram, or ECG. 
The electrical voltages created by the heart have been 
well-known lo the medical rimimiinity for nearly a centu- 
ry. In the beginning the ECG was measured by sensitive 
galvanometers with the patient's hands arid feet placed in 
vessels filled with saline solution. Improvements in the 
assessment of diagnostic ECG signals have been closely 
related to the evolution of electronics, great strides lieing 
made when amplifying devices such as vacuum tubes and 
later transistors became availahle. Today, low-noise opera- 
tional amplifier circuils are state-of-the-art for ECG signal 
processing. 

Physiologically, the polarization and depolarization of the 
heart's muscle mass creates a three-dimensional electrical 
field that changes with time. As a result, voltages can he 
measured on the surface of the body that represent the 
pumping cycle of the myocardium. A strong effort has 
been made to standardize the points at which the volt- 
ages should be measured. The most widely used are three 
differential voltages: From right arm (RA) lo left ami 
(LA), from IA to left leg (1,L), and from LL lo RA. These 
voltages are known as ECG leads I, 11, and 111. The light 
leg electrode (KL) acts as the neutral poll' in this system. 
This configuration is known as the Eindhoven triangle 
(see Fig. 1 >, 



ECG Signal Characteristics 

The amplitude <>f the ECG signal as measured on the skin 
ranges from 0.1 mV to 5 mV. The frequency extends from 
0.05 Hz to 130 Hz. Physiological signals like (he ECG dif- 
fer from artificial signals in that they are not reproducible 
from one time segment lo another. They are more statisti- 
cal in nature and have larger variations in signal charac- 
teristics than, say, a signal generator output. This places 
additional requirements on the measurement system, espe- 
cially the analog input stages. .Although the average ampli- 
tude is only around 1 mV, there are large dc offset volt- 
ages because of electrochemical processes between the 
electrode attached to the patient and the patient's skin. 
These can be as high as ±500 mV. Also, the contact resis- 
tance between an electrode and the body surface can 
vary widely and reach values around 1 Mil. In addition, 
the system must be capable of detecling that an electrode 
has fallen off the patient Perhaps the largest constraint is 
the presence of 60-Hz or 50-1 Iz power line noise. The 
human body acts like the midpoint of a capacitivc divider 
between one or more power lines and ground. Thus, com- 
mon-mode voltages its high as 20V p-p can be superim- 
posed on lite body. Eliminating Ibis source of noise is one 
of the major tasks of an ECG amplifier. Fortunately, the 
ECG signals are differential signals while I he power line 
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Fig. 1. I "Ijii-i-jih -in oriSCXi electrodes. The colors of the cabling 
system are standardized. The right leg ( \tL) connection acts as the 
neutral pull'. (In monitoring applications the HI. anil I.I. connections 
an- oil en as shown here and not on the legs.) 

voltages are common-mode, so I lie noise can be reduced 
with differential amplifiers. 

Another requirement results from artificial pace pulses 
used to Stimulate the heartbeat of some patients. Pace- 
maker devices are implanted into the chest, generating 
small pulses up to IV p-p al frequencies in Ihe kilohertz 
range. Pace pulses are superimposed on the EGG signal 
and have to be detected to differentiate Ihem from the 
peak value of the ECG signal, called Ihe QRS complex. 
This is important because the heart rate measurement is 
based on this QRS signal, and an incorrecl interpolation 
would result in an incorrec l value. 

In emergencies when the hearl stops beating (ventricular 
fibrillaiion). a commonly used procedure is to apply a 
voltage pulse of about 5 kV p-p with a 5-ms duration to 
synchronize Ihe neural Stimulus of Ihe heart's muscle 
mass and bring it back to normal operating conditions. 
Because of the high vollages needed to defibrillale a pa- 
tient, Ihe inputs of Ihe ECG circuit must be protected. 
Other sources of noise are cleclrosurgery devices, which 
are used in operating rooms as electronic scalpels. These 
devices contain high-frequency currenls in the megahertz 
range. The high current density at the lip of the electrode 
coagulates Ihe protein, thereby slopping bleeding. The 
ECG module must provide additional filtering againsl I his 
high-frequency noise. 

Integrated Solution 

The design goals for the Component Monitoring System 
ECG module included reduced cost, reduced size, mini- 
mum power consumption, and increased reliability and 
I'unciionalitv compared to the current patient monitor 
generation. 

The target size was a single-width parameter module. This 
module measures only 99.6 mm by 36 mm by 97.5 mm 



(3.9 in by 1.4 in by 3.8 in). It was therefore obvious that 
we would have to use surface mount technology to meet 
the size objective. In addition, it soon became apparent 
that a large percentage of the electronic circuit would 
have to be Integrated in silicon if the entire device was to 
fil into a single-width module. This and the need for cost 
reduction Oil such a high-volume parameter module as the 
ECG module clearly indicated that an application-specific 
integrated circuit (ASIC) would be ihe appropriate solu- 
tion. 

The Investigation revealed that the chip size we had in 
mind and the mixed analog-digital design were real chal- 
lenges for a fully custom ASIC. Our plan was to integrate 
the following funclion blocks into a single chip: 
Full three-channel ECG amplifier with various filter 
stages of both analog and switched capacitor type 

• Precision resistor network for the weighting function 

• Three-channel lead select multiplexer 

• Precision differential amplifiers wilh high common-mode 
rejection ratio 

• Eight-channel multiplexer for sequential scanning of all 
analog signals 

• Bandgap voltage reference 

• 10-bit analog-to-digital converter (ADC) 

• Digital control logic for switching filter comer frequen- 
cies, multiplexers, and other circuits 

• Serial interface to connect the chip with Ihe surrounding 
circuits. 

To be able to integrate all this, a 3-Um CMOS process 
was chosen. II is a p-well LOCOS process with polysilicon 
gales and ion implantation. NMOS and I'MOS field-effect 
transistors are combined. Also available are n-channel 
JFETs and pup bipolar transistors. The thin-film resistors 
are laser trimmahle to within 0.1% matching. Available 
cells include .IFET operational amplifiers, bipolar opamps, 
switched capacilor filters, 8-bil to 14-bit analog-lo-digital 
and digilal-to-analog converters, and sample-and-hold am- 
plifiers. 

The Elec trocardiograph ASIC 

The basic functions of the EGG circuit can be seen in 
Fig. 2. which shows one of the three independent chan- 
nels. The inputs are switched to the HA and LA elec- 
trodes as active inputs. The RA and LA inputs of the chip 
arc connected to the patient. Protection circuits against 
ESD and defibrillator pulses and current-limiting resistors 
are provided outside the chip on the printed circuit 
board. JFET input opamps amplify the signal live limes 
and act as high-impedance input buffers. A precision re- 
sistor network (Wilson network) sums the various elec- 
trode voltages to achieve the standard voltages for the 
different ECG selections. The multiplexer selects the ap- 
propriate lead voltages from the resistor network. The 
10-kIIz low-pass fillers act as prefillers for anti-aliasing 
purposes to reduce the high-frequency components in 
case an cleclrosurgery unit or other high-frequency noise 
source is coupling into the module. These are analog fil- 
ters. They protect ihe switched capacitor filters with their 
time-discrete sampling system againsl unwanted aliasing 
disturbances resulting from high-frequency noise. 
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Fig. 2. Basic structure Of the ECG 
ASIC (one of three channels). 



The RI. input acts as the neutral pole, hut is not directly 
connected to analog ground. It is I he low-impedance out- 
put stage of an inverting summing amplifier (called the 
right leg drive) which serves as a feedback circuit, further 
reducing common-mode power line voltages. The com- 
mon-mode signal present at the output of the lead select 
multiplexer Ls phase inverted and fed back to the patient, 
thus being subtracted from the common-mode voltage 
present at the inputs. This helps eliminate unwanted pow- 
er line noise. 

The difference between the two selected electrode signals 
is derived in the differential amplifier section, which has 
a gain of one. lip to that point, all gain variations and 
tolerances affect the common-mode rejection. Therefore, 
these stages have laser-trimmed resistors where appro- 
priate. 

At the outputs of the differential amplifier in each of the 
three channels, the signal path is split into two parts. For 
the two main channels, the auxiliary path goes out of the 
integrated circuit to the pace pulse detector. The pace 
pulses are identified by their higher-frequency content in 
the range of 1 to 4 kHz, but only the presence of a pace 
pulse has to be detected, not the time dependent signal 
itself. Therefore, it Ls unnecessary to construct the whole 
signal path with this large bandwidth. Alter the pace 
pulse detector output, low-pass filtering of the K('G signal 
begins. 

For BCG filtering, a minimum lower corner frequency of 
0.05 Hz is required. The large capacitor and resistor val- 
ues needed could not be integrated and therefore the 
signal is routed from the chip into external filter sections, 
one Tor each channel. By means of interna! switches, 
three low-end comer frequencies (0.05 II/., 0.5 Hz, ;X5 II/.) 
and two high-end corner frequencies (40 II/. and ISO Hz) 
can be selected, 

The signal Hows out of the chip, through the external 
fillers, and back into the chip. It then goes through the 
main gain stage, which has switchable gain of 10 or 100 
depending on the signal amplitude and the resolution 
needed on the screen. After passing the gain stage, the 
signal is filtered with a second-order switched capacitor 
stage to achieve the corner frequency of 1-tO II/. with as 
small a tolerance as possible. 



The three analog chaimeLs described so far are connected 
to the inputs of a one-of-eighl multiplexer, which sequen- 
tially scans these three channels and five auxiliary chan- 
nels every' - milliseconds. The output feeds into the ADC, 
a 10-bit convener thai has less than ±1 LSB differential 
nonlinearily and a conversion time of 20 us. An 
8-by-10-l>ii dynamic random access memory holds .ill the 
conversion results temporarily until they are transmitted 
via a parallel-lo-serial converter out of the chip to the 
module microprocessor, hi the opposite direction, all con- 
trol information is transferred into the chip over this seri- 
al interface and latched. The use of a serial data conver- 
sion scheme made it possible to use only three output 
lines and a 28-pin package. 

Fig. :i is a photograph of the ECG ASIC chip. 
Pace Pulse Detection Circuit 

The dual pace pulse detector is also an ASIC. Its analog 
pans are built entirely in switched capacitor technology. 
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Fig. 3. Photograph of the EGG ASIC wafer The analog functions 
cover much teaser areas than the digital pans. 
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Fit?. 4. M1001 ECG module pruned 
circuit boards The large capacitors 
on the left hoard are part of the ex- 
ternal filter stages. The BGG ASIC 
is just iri front of these capacitors. 
The PPI) is to the left of the ASIC. 
The right hoard contains the digital 
parts of the mod tile. 



This had I he advantage of avoiding laser I rimming, mini- 
mizing wafer area, and thus reducing cost. This chip gen- 
erates two logic output signals for each channel, indicat- 
ing whether a pace pulse witli either positive or negative 
polarity is present in the input signal. The information is 
polled by the microprocessor and sent to the algorithmic 
software. 

Test Considerations 

It was clear from the beginning thai testing the ECG chip 
would be a challenge because of the large number of 
parameters to he measured. The specifications describing 
the functionality are split into two parts: internal and ex- 
ternal specifications. The internal specifications can be 
tested with wafer probes and help the vendor optimize 
the production process. They are consistent with the ex- 
ternal specifications, which are measurable from outside 
the chip anil are accessible to the customer. The external 
specifications are the link between the ASIC design and 
the printed circuit board design and were used as guide- 
lines throughout the design and verification process. Auto- 
mated test equipment has been set up at IIP to test the 
ECG chip via its serial interface. The same test equipment 
is used by both the vendor and HP to reduce the number 
or false measurements resulting from different measure- 
ment setups. 

Results 

Fig. 4 shows the printed circuit boards of the Ml (It II ECG 
module. All components between the ECG ASIC (the larg- 
er one) and the input patient connector are for protection 
and filtering against defibrillator pulses, electrostatic dis- 
charge, and electrosurgery units. The following (able gives 
an overview" of the two ASIC chips ( PPI) is the pace 
pulse detector): 



Item 

Die Size 

Analog Functions 

Digital functions 

Number of Transis- 
tors 

Number of Digital 
Gates 



ECGASIG PPDASIC 
fi.22 by 6.27 mm 3.43 by 3.99 mm 



2-1 
4 

= 6000 
=550 
28 PLCC 



12 

2 

= 2000 

=200 

20 PLCC 
I ". mW max. 
±3V 



Number of Pins 

Power Consumption 275 m\V max. 

Dynamic Range ± 3 V 

Overall Analog Gain 800 

Noise (referred to 2 LSB 
input) 



The main problem that was faced in this design project 
was the complexity of the system, which caused side ef- 
fects thai were not visible in the beginning. The die size 
was too big for normal packages, so packages with larger 
cavities had to be found. The simulation time was longer 
than expected because of the large number of compo- 
nents inside. 

In summary, the design objectives were met. The ECG 
performance is state-of-the-art, and significant reductions 
in cost, power consumption, size, and component count 
were achieved in comparison to a discrete solution, 
which probably would have required a double- width 
module. 
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A Very Small Noninvasive Blood 
Pressure Measurement Device 



This small assembly covers the entire blood pressure measurement 
spectrum from neonates to adults. The packaging of the air pump 
assembly makes several contributions to the objectives. 

by Rainer Rometsch 



The noninvasive blood pressure module of the HP Com- 
ponent Monitoring System is a double-width parameter 
module used to measure and calculate a patient's systolic, 
diastolic, and mean blood pressure. The method Is based 
on inflating a cuff on the patient's arm until all blood 
flow is suppressed in this extremity. The pressure in the 
cuff is then slowly deflated, and by using the oscillomet- 
ry- measurement teclmique, both the high ami low blood 
pressures -and the mean value can be determined. 

Physically the noninvasive blood pressure module consists 
of two parts. One is the electronic board, which contains 
the power supply, the signal acquisition circuitry, and the 
interface to the computer module. The other is the pump 
assembly, which is responsible for the controlled inflation 
and deflation of the cuff. 

Requirements imposed on the pump assembly WOW: 

• Low parts price 

• Minimum number of parts 

• Robust construction 

• Easy to assemble in the parameter module 

• Low power consumption at the highest possible pump 
capacity. 

Because of the required size of the pump assembly (it 
had to lit in a single-width parameter module), and the 
need to reduce the number of individual parts, a totally 
new approach was taken in the design of this mechanical 
part. The solution implemented is a self-contained func- 
tion block allowing a stringent separation between the 
electronic printed circuit hoard and the pneumatic system 
(see Fig. 1 ). 

The Pump Assembly 

The pump assembly consists of the pump and two valves. 
The pump is a membrane device driven by a dc motor. 
To meet the requirements of the application, the pump is 
optimized for high pumping capacity and low air leakage. 
Air leakage is a big concern because the volume in the 
cuff lias to ' .• leflated in a highly controlled fashion. This 
is especb'.y difficult for neonatal applications, because 
neonates CUffS have very small volumes. We solved the 
problem by incorporating a reflow valve within the pump 
module. This pressure valve opens at low flow rates, and 
therefore does not increase power consumption. The im- 
portant thing is that it seals tightly at a very low reflow 
rate* 




Fig. 1. Pump assembly of the rompon'Mil Monitoring System noniiv 
vnsive blood pressure measurement Module. 

The second element in the pump assembly is a pair of 
valves. Hanged to a machined aluminium extrusion. Two 
valves are needed to provide a fail-safe circuit that will 
comply with the safety requirements imposed on noninva- 
sive blood pressure measurement devices. These two 
valves have considerably different flow characteristics. By 
automatically switching between the two valves, one non- 
invasive blood pressure module covers the entire applica- 
tion spectrum from neonates' cuffs all the way to adult 
thigh cuffs. 

The aluminium extrusion is designed to replace all (he 
necessary tubing between tin- pump and the valves. It is 
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therefore possible to flange the mounted valve onto the 
pump without any additional rubber tubing. This contrib- 
utes to a part count reduction and simplifies production 
dramatically. 

The only connections (hat have to be made with the 
pump assembly are a in-mm-long rubber tube to the non- 
invasive blood pressure connector in the parameter mod- 
ule, and a power connection to the electronic board for 
Ihe dc pump. The rubber lube to Ihe noninvasive blood 
pressure connector is essential because this flexible tub- 
ing detaches the pump from the the parameter module 
housing and thus helps damp acoustic noise caused by 
mechanical vibration. 

Packaging 

The entile pump assembly is encapsulated in a polyure- 
Ihane package. This relatively simple part contributes in 
more than one way to the goals of Ihe overall soluiion. 
All noise generated by the dc pump is muffled by the 
package to a degree I hat is acceptable in Ihe hospital 
emironment. The pump assembly survives the 1-m drop 
test because sufficient kinelic energy is absorbed by Ihe 
package to avoid damage lo the mechanics. Packaging of 



this part for shipment from the vendor to HP has been 
minimized to a simple protective cover. 

The outline of the foam package is identical to ihe inner 
contour of the parameter module. Therefore, no additional 
parts are needed to embed Ihe pump assembly in the 
inner enclosure of Ihe parameter module. The elimination 
of additional screws or clamps has helped reduce produc- 
tion time and part count 

Conclusion 

The Component Monitoring System noninvasive blood 
pressure module meets all of Ihe above described objec- 
tives. Because Ihe pump assembly and the electronic 
board are delivered as prefabricated parts, ihe total lime 
lo build the module has been reduced to about two min- 
utes. The result is a small, robust, self-contained noninva- 
sive blood pressure module, to our knowledge one of the 
smallest noninvasive blood pressure devices in the world. 
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A Patient Monitor Two-Channel 
Stripchart Recorder 

Small enough to fit in a double-width HP Component Monitoring System 
parameter module, this recorder embodies simplicity of design, a highly 
tooled mechanism, and sophisticated printhead power management. 

by Leslie Bank 



The medical environment requires a record of Ihe care 
Ihat has been given to a patient, both for Ihe palicnt's file 
and as a legal document. For patienl monitoring equip- 
ment like the IIP Component Monitoring System, the re- 
cord has traditionally been a conlinuous slrip of paper of 
various widths. An example of a recording from the Com- 
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ponent Monitoring System's two-channel recorder is 
shown in Fig. 1. Fig. 2 is a photograph of the recorder. 

In ihe past, the hospital had three options lo provide re- 
cording capability for a paiient. each of which was less 

than ideal: 



J I L I 




26 ( lefohet 1991 I lc« tell Packard Journal 

©Copr. 1949-1998 Hewlell-Packard Co. 




/ 



Fig. 2. The III' Component Monitoring System twn-ehannd recorder 

module 

Purchase a recorder for every bedside. This is very ex- 
pensive in these days of cost containment.. 
I'se a central, shared recorder. With much of Ihe patient 
care given at Ihe bedside, not having a recorder nearby is 
a distincl disadvantage. 

Mount Ihe recorder on a cart and wheel it to the bedside 
when needed This takes up loo much of the available 
room at Ihe bedside and is also inconvenienl. 

The Component Monitoring System philosophy of allowing 
Ihe monitor configuration to change with the patient's 
needs extends to the recording function, The iwo-channel 
recorder can be moved around like any other parameter 
module. This approach, along with Ihe requirements for 
ease of use. high reliability, high performance for many 
types of applications, low manufacturing cost, and low 
power led to the following set of major specifications: 
Size: Double-width parameter module 
Power consumption: Approximately (i watts maximum 
Number Of waveforms: 3 
Lines of character printing: 3 

Paper Ml-mm-hy-30-m rolls (fan-fold paper would not 111 
in Ihe desired package size). 

These Specifications resulted in a number pf major techni- 
cal challenges, 

Size. Filling the paper, motor and drive mechanism, elec- 
tronics, and supporting structure Into a package of this 

size was a major accomplishment. 

Power Consumption. Chemical thermal papei is used in I his 
recorder. A printhead consisting of a linear array of resis- 
tors is in conslanl contact with the paper. When power is 
applied to one of these resistors, Ihe resistor gels hoi and 



a mark is made on the paper. This, combined with the 
power requirements of the motor and electronics, normal- 
ly would require much more power than the (> watts that 
are available. In addition, there can be no ventilation in 
the housing. Meeting the high-temperature specifications 
was difficult because of the internal heat generated by 
the power-consuming components. 

Ease of Use. Recorder operation should 1k» flexible to meet 
the various medical applications. It should be intuitive for 
the occasional user. Most of the Component Monitoring 
System recorder operation is part of the normal control 
structure. The difficulty for the recorder design team was 
to make the paper loading easy while not using any pow- 
er to aid paper feeding. 

Reliability. Recorders, which have moving parts that wear, 
lend to be less reliable than equipment that does not 
have moving mechanical pans. A simple mechanical de- 
sign along with high-quality components and a severe 
testing program resulted in a highly reliable product. 

Manufacturing Ease. This recorder was designed for 
high-volume assembly. Much effort was spent in minimiz- 
ing part count, in using the molded parts to perform mul- 
tiple functions, in designing adjustments out. and in mak- 
ing the instrument easy to test. 

Mechanism 

Paper is loaded by opening a door and inserting the roll 
Of paper into the paper compartment. The paper is then 
threaded around a drive roller and [Hilled taut, and the 
door is closed. As the door is closed, a cam is engaged 
which lowers the printhead. The roller is driven by a 
Stepper motor which is connected to the drive roller by a 
drive belt. The roller is driven when the motor turns. The 
paper has enough wrap around Ihe drive roller to ensure 
thai it can be driven under the printhead. Enough back 
tension must be provided to make the paper track proper- 
ly, yet too much tension increases Ihe motor torque re- 
quirements, which in turn increases the power required. 
This tumed into an inl cresting design trade-off. Sealed 
ball bearings are used on the drive roller to minimize 
power requirements while keeping paper dust out of the 
bearings. 

Two tinocl ion-molded frames form Ihe chassis. The print- 
head and drive roller are captured between the chassis 
halves, while the motor, paper door, power supply board, 
and digilal board are all mounted to Ihe oulside of the 
chassis. The entire assembly is enclosed in a double- 
width module ease. 

Electronic Hardware 

The digilal board contains two Intel S0C196 Ill-bit micro- 
controllers which communicate with each other via a 
shared RAM. Each microcontroller contains a serial port. 
The I/O processor uses its serial port to communic ate 
wilh the monitor's computer module via the parameter 
module interface (see article, page l!l). It receives digilal 
commands, waveforms, and lexl data from Ihe monitor. It 
Interprets ihe commands and transforms the data into a 
format compatible with Ihe printhead. It also monitors Ihe 
front-panel and door-open switches and Ihe paper-out sen 
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sor. The I/O processor communicates the recorder status 
to I he monitor. 

The other processor takes the information from the I/O 
processor and ships il to the printhead via its serial pott 
The energy applied to each resistive dot in the printhead 
is tightly controlled by varying Ihe prinlhead strobe limes. 
This ensures high-quality printing and long printhead life 
with minimal energy use. This processor varies Ihe prinl- 
head strobe based upon prinlhead temperature, resis- 
tance, and voltage, which are measured by ihe onboard 
analog-to-digital converter. The motor speed data is also 
sent to the motor drive chips, which are located on the 
power supply board. 

The power supply board transforms the volts received 
from the monitor into 15 volts required by the prinlhead 
and motor, and into the 5 volts required by ihe logic. This 
power conversion is performed by a sw itching power sup- 
ply with a typical efficiency of 8896, The motor is driven 
by two Stepper motor chips which, under conlrol from 
the digital board, microslep the motor to provide accurate 
chart speed wilh minimal power. The peak energy 
supplied lo Ihe prinlhead is provided by a large capacitor. 
In case of extremely heavy printing, the power lo the 
printhead may sag. To prevent Ihe 15-voll supply from 
sagging" too much, a currenl limiter is placed between the 
prinlhead energy storage device and Ihe 15-voll supply. 
Finally, the optical isolators for the serial dala lines lo 
tin- monitor are on this board. 

Printhead Control 

Character and grid general ion are provided by the record- 
er. The selecled characters and grid are combined with 
ihe waveform data, rasterized, and sent (o the printhead 



10 energize a number of resislors (dots) in I he prim head. 
The printhead is loaded three limes for each dol printed. 
If Ihe dol has nol been fired and is "cold", il is fired for 
all Ihree loads. If the dot has been fired in the last cycle, 

11 is "hoi" and is fired for only one load. If (lie dol has 
been fired Iwo cycles ago, it is "warm" and is fired twice. 
This results in a historical firing of each individual dot 
and precise temperature control of each dot. In addiiion. 
each of Ihe three loads is accompanied by a strobe of Ihe 
prinlhead. Kaon strobe lime is varied based upon prim 
head voltage, temperature, resistance, and chart speed. 
For example, as the temperature of Ihe prinlhead in- 
creases, ihe amount of energy provided (o all dots de- 
creases. This results in a lower prinlhead temperature 
rise and less thermal shock to the dol resistors, while 
providing consistenl prinling quality. In addition to all 
ibis, Ihe enlire printed area is dithered up and down over 
lime. This equalizes Ihe use of all Ihe prinlhead resistors 
and improves Ihe life of Ihe prinlhead. 
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Patient Monitor Human Interface 
Design 

A design based on human factors leads to an intuitive and easy-to-use 
human interface for the HP Component Monitoring System. 

by Gerhard Tivig and Wilhelm Meier 



The design of the human interface for the HP Component 
Monitoring System involved a coordinated effort of R&D, 
marketing, and industrial design, working with valuable 
inputs and feedback from tiie principal users — the inten- 
sive care unit (Id) nurse and the anesthesiologist. Fig. 1 
illustrates the basic elements of the design process for 
the human interlace. 

The functionality of the Component Monitoring System 
goes beyond the classical real-time patient monitoring 
functions. The monitor offers extensive support for medi- 
cal procedures, such as cardiac output and S-T depres- 
sion and elevation measurements, a powerful data man- 
agement capability with various calculation and report 
facilities, and a review facility for alarms and patient in- 
formation from "another bed" using the proprietary IIP 
serial distribution network (SDN). This functional com- 
plexity had to be handled wilh a single consistent and 
simple operating Structure so thai il did nol lead to a 
complex user interface. Because il is a key elemenl in the 
user's ultiniale buying decision, usability was a critical 
issue in the design. 
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Environments and Users 

The Component Monitoring System is used In a variety of 
environments, including the surgical I(T. the neonatal 
and cardiology ICUs. and the operating room. There is a 
wide spectrum of users, including the nurse in the ICUs 
and the nurse anesthetist, the anesthesiologist, and the 
perfusionist in ihe operating room. 

The primary user in the operating room is the anesthe- 
siologist. Some of the tasks performed are of a clerical 
nature, such as logging patient and life support device 
data, observing the monitor, and scanning Ihe area. There 
are also physical tasks, not directly related to the moni- 
tor, such as patient preparation, administration of drugs 
and Quids* and patient observation. 

In (he surgical and neonatatal IC1 ; s, 90% of users are 
nurses. The tasks performed by the nurse include 30% 
Clerical activities, such as recording medical data, writing 
down and checking doctors' orders, writing down the 
medication plan, and filling out the palienl's flowsheet 
The other 7096 of the tasks performed are of a physical 
nature, such as administering fluids and drugs, taking 
measurements, making physical examinations, ensuring 
patient hygiene, and performing medical procedures. 

In most cases, nurses and physicians have no computer 
experience. Il can be expected that many of them will 
have doubts about the introduction and use of comput- 
er-based monitoring equipment. Therefore, il was consid- 
ered advisable not to make the Component Monitoring 
System look like a computer. 

The main focus is on Ihe patient. The nurses and the phy- 
sicians do not have time CO interact extensively wilh the 
monitor. They are in a crowded and stressful environ- 
ment, where il is not unusual to encounter critical situa- 
tions requiting immediate action to prevent degradation of 
the patient's situation. Clinic al personnel also face a wide 
variety of equipment from different manufacturers, all 
with different user interface standards. 

Equipment training often includes no more than one or 
two hours of instruction at monitor installation time. The 
turnover of the nursing Staff may be very high. Because 
the workload is heavy, there is no time to read extensive 
operating manuals, instruction cards, or help lexis. Be- 
cause of economic pressures on Ihe health care system 
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and clinical personnel shortages, especially in nursing, 
less lime is available for in-service (raining. 

All of this suggests Ihal inluiliveness and ease of use are 
fundamental requirements for the Component Monitoring 
System human interface. 

Design Objectives 

As the performance and Computational power of a patient 
monitor increase, the challenge is how lo present and use 
the medical Information provided by the monitor in an 
easy-to-interpret, simple, interactive way that will lead to 
more efficient patient care delivery. It is possible to con- 
trol a monitor with two buttons and a lot of key pushing 
and watching. It is also possible to have 100 bullous or 
more for the same job and assign a distinct function lo 
each bullon. An optimum is somewhere in between. 

The main goal was to design a consistent control struc- 
ture for all applications in the monitor and across all 
present and future members of Hie Component Monitoring 
Syslem family. Working towards a simple model in the 
user's mind was considered more important than reducing 
the number of keystrokes required to access a given func- 
tion to an absolute minimum. Having formed a model of 
how the syslem operates, the user can extrapolate how a 
particular function might work. If the system is consis- 
tent, the user's prediction will work, Ihe syslem will be 
perceived as easy lo use. and user acceptance and Satis- 
faction will increase. The Control Structure needs lo be 
self-explanatory lo Ihe novice user and allow fasl access 
lo the experienced user. Access lo critical functions re- 
quiring Immediate action (like silencing an alarm or freez- 
ing Ihe screen) should be simple and fasl and should not 
interrupt the user's activity in a given operating window. 

Minimizing operating complexity by reducing the number 
of nested operating levels and thus eliminating the need 
for "navigation aids" has been a major quantitative goal. 
Each Component Monitoring Syslem function is accessible 
within three operating levels, reinforcing Ihe same access 
lo all functions: There is a home key, labeled Standard Dis- 
play, which always brings Ihe user hack lo Ihe standard 
resting display. Because monitoring functions vary in their 
complexity, Ihe human Interface design implements simple 
things in an easy way while making complex lasks possi- 
ble. 

Elements of the Human Interface 

The main elements of Ihe Component Monitoring System 
human interface can be seen in Fig. 6 on page 12. All 
user interaction mid data visualization lake place through, 
a human interface unit consisting of a 14-inch high-resolu- 
tion display (monochrome or color) and a keypad inte- 
grated in the screen bezel, Optionally, a remote keypad 
can be attached to the Component Monitoring System 
through Ihe standard Ill'-IIII. interface; The remote key- 
pad duplicates all of Ihe keys on the screen bezel and 
has mi additional alphanumeric entry capability. The 
screen bezel also contains Ihe sound generator for the 
alarm interface and Ihe visual alarm indicators, which are 
color-coded alarm lamps (red, yellow, green). The controls 
and lights on each patient parameter module are inte- 
grated into the overall operating concept. Each 



single-width parameter module has one or two keys. One 
key is always a setup button, which allows direct access 
to Ihe setup menu for Ihal parameter module. The oilier 
key is optional and allows quick operation of functions, 
such as zeroing a transducer, starling a cardiac output 
measurement, or calibrating Ihe C0 2 analyzer. 

Most operations are controlled by a mix of twelve hard- 
keys and seven softkeys. A group of arrow keys on the 
right side of the keypad (up, down, left, right, confirm i 
support the pointing and select functions of Ihe user in- 
terface. 

Hifsim and Its Benefits 

The control structure and Ihe screen layout were exposed 
lo nurses, physicians, and anesthesiologists in Ihe early 
stage of the design process. This was possible through 
the use of a simulation tool. 

Al ihe lime Ihe human interface design started, very few 
Simulation tools were available, and in most cases they 
didn't match the designers' requirements. We chose lo 
develop our own simulation tool, called Hifsim, This look 
four engineer-months. Hifsim runs on an HP !I0()0 Series 
300 workstation under the IIP I X operating system. 

The intended use of the Hifsim tool for usability tests 
made it mandatory lo come up with a keypad Integrated 
into the screen bezel lo resemble as much as possible the 
way a nurse would Interact with the monitor, Similar pix- 
el resolution and useful screen size to that of the final 
monitor were mandatory. 

ESpecial hardware was developed for Ihe simulator. It con- 
sists of a metal cover over Ihe workstation's 19-inCfl dis- 
play, leaving an opening similar lo Ihe Component Moni- 
toring System's useful screen area. An lll'-ll. bullon box 
was modified as a keypad replacement and was Inter 
grated into the cover. The electronics of Ihe button box 
were used lo connect a set of hardkeys embedded into 
the screen bezel, forming a close approximation of Ihe 
final screen bezel layout (see Fig. 2). 

Hifsim has two main sections: the screen generator and 
Ihe simulation seel ion. The screen generator is basically a 




Fig. 2. The Hifsiin simulator hardware interlace resembles the Com- 

ponenl Monitoring Systems. 
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compiler thai interprets the Hifsim screen definition lan- 
guage and converts it into commands for the HP Starbase 
graphics software. This language is adapted to the charac- 
teristics of the planned Component Monitoring System 
display hardware in terms of resolution, character sizes, 
fonts, colors, and special graphic elements, 

The benefits of the screen generator are: 
Serv es as a screen design tool 
Ensures consistency in screen design 
Enabled early selection of the Component Monitoring 
System color scheme 
Generates "screen cookbook" 
Supports usability tests 
Aids in software implementation 
Supports trade shows, demonstrations, and training. 
Both sections of Hifsim are data driven. This means that 
the screen and operating dependencies are described in 
files. Every change in the screen content or operating 
sequence is implemented by editing these files while Hif- 
sim is running. This supports the idea of interactive 
screen design and makes Hifsim a true screen design 
tool. 

The monochrome version supports two intensities of 
green. Up to eight colors can be used in the color version 
of Hifsim. Each color can appear with lull or half intensi- 
ty. Again, similarity to the final display hardware attri- 
butes was mandatory for the simulator, and the color 
map of the workstation made it possible to generate any 
desired color. This allowed us to come up with a good 
definition of the Component Monitoring System color 
scheme under the restriction Of file available hardware 
veiy early in the human interface design process. 

Building a screen means specifying file screen objects 
along wilh their attributes in terms of color, size, posi- 
tion, line style, and so on. The ability to define waveform 
objects in terms of wave amplitude, trace length, position, 
and color was essential for the proper design of the real- 
timc Waveform display. The SCieen definition language 
Supports primitives for text, Waveforms, rectangles, size 
bars, value and alarm bars, lines, and polygons. 

Hifsim made it possible for the human Interface design 
te&m to Visualize and distribute the screen design in the 
"screen c ookbook", which is a collection of about 200 
screen hardcopies bundled together to illustrate the Com- 
ponent Monitoring System human interface design. The 
cookbook was an essential element in the human inter- 
face design process. It was used to gel clinical user and 
III' management feedback and approval very early in the 
design process. 

The effort spent in building Hifsim was repaid during the 
implementation Of the human interface software. All 
screen definition details were used in the actual software 
implementation wilh virtually no changes. The implemen- 
tation of the interface's task window command language 
resembles the primitives used in the Hifsim screen defini- 
tion language. 

The basic functionality of the Component Monitoring Sys- 
tem was developed jointly with the IIP Wallhain Division 
in the I'.S.A., and Hifsim was used there as well for 

screen designs and simulation in parallel with 'he u&n 



effort at the Boblingen Medical Division. This helped 
achieve inherent consistency. Because the same tool was 
used to generate all of the Component Monitoring System 
screens, the screens' look and feel are consistent across 
ail Component Monitoring System functions. 

Hifsim was used widely in exposing the human interface 
design during shows, demons! ration sessions, and market- 
ing training at a time when no finalized Component Moni- 
toring System hardware or software was available. This 
allowed the design team to get very early feedbac k on its 
user interface design. 

Usability Testing 

Hifsim was a prerequisite for being able to set up the 
Component Monitoring System usability tests. The pur- 
pose of the usability tests was to discover which features 
of the human interface design were effective and which 
needed to be improved, and to do this testing early in the 
design process where changes could still be made in the 
human interface design. 

An extensive usability test session was organized in the 
Boslon area by an independent research institute thai 
specializes in human interface studies and human factors 
research. Our objeclive was to conduct an independent 
evaluation of the monitor's user interface, basically the 
control Structure and the screen layout The test was con- 
cluded on a Sample of 13 nurses and anesthesiologists 
who were asked to perform typical patient monitoring 
tasks. A second objective was to assess the value of us- 
ability tests as an aid !o the design process of a monitor's 
user interface. 

A game plan was worked oil! that included a list of 30 
different Scenarios commonly performed by the clinical 
personnel in operating rooms and the ICUs. The test ses- 
sions were conducted by a moderator who first read the 
task scenario and then asked the test subjects to perform 
it. .Ml sessions were videotaped and members of the 
Component Monitoring System R&D and inarkeling teams 
watched them in a separate room. This way Ihe design 
engineers got firsthand insights into user reactions to the 
human interlace. 

Before each session Ihe moderator gave a very brief ex- 
planation about how the monitor works. This demonstra- 
tion was kept to a minimum to lesl how easy it would be 
for a nurse to operate the monitor wilh almosl no pre- 
vious training. The tesl subjects were asked before the 
lest what functionality Ihey expected to activate with 
each hardkey. In this way we got more feedback on how 
intuitive Ihe Component Moniloring System keypad label- 
ing was. 

Al the end of each session Ihe lesl subjects were asked 
to pretend that they had to Main the moderator to do a 
simple procedure, such as changing the leads on the EGG 
or acfjusling the pressure alarm limits. The purpose was 
to see if they could recall the procedure Ihey had per- 
I'onucd about an hour ago. This was a measure of how 
well Ihey had learned and how well they understood the 
Operating concept. 

The general assessment was lhat the Component Monitor- 
ing System user interlace is sound, easy to learn, and 
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effective to use. A significant number of recommendations 
and problems were found, many of which had not been 
reported in previous tests will) clinical specialists and III' 
employees. For example, the monitor has a function that 
allows the user to activate or suspend the monitor's 
alarming capability. This function was implemented in the 
prototype as a toggle key. To suspend alarms, the user 
had to press a softkey labeled Suspend Alarms. The label 
then changed to Activate Alarms and an ALARMS SUSPENDED 
message appeared in the upper part of the screen. The 
subjects frequently overlooked the message. They were 
therefore confused to see the softkey label changing to 
Activate Alarms. They were not sure whether the alarms 
were on or off. Even with extensive explanations, they 
had trouble understanding the functionality of the toggle 
softkey. Because this is a critical function that involves 
patient safely, we separated this function into two sepa- 
rate soft keys. 

The recommendations from the usability tests were incor- 
porated in the human interface design and new tests were 
conducted. After these were successfully passed, the hu- 
man interface BUS (external reference specification) was 
finalized. 

The usability tests were an essential milestone in the hu- 
man interface design process. However, the tests only 
evaluated the system's ease of learning and initial ease of 
use. They did not evaluate how users would feel about 
the monitor after they had used it on a daily basis. The 
basic difference is that users who know the monitor don't 
read labels anymore. They simply push keys in a "pre- 
slored" sequence. This emphasizes the importance of con- 
sistency in the Component Monitoring System human in- 
terface design. In addition, these tests did not reflect how 
the user would interact with the monitor in a clinical 
environment, in critical situations where fast access to 
some basic functions is essential. Let's come back to the 
example of the suspend/activate alarm function, finally 
Implemented With two softkeys. After release of the Com- 
ponent Monitoring System, we found that users in the 
operating room require a one-push key to suspend or acti- 
vate the monitor's alarms. This is the way they are used 
to operating other monitoring equipment. In addition, hav- 
ing direct access to the alarm suspend function helps the 
user whenever special procedures are done on the patient 
that require alarm suspension. This led to the decision to 
add a hardkey on the keypad for the suspend/activate 
alarm function. 

The verification process did not stop here. Tests in the 
clinical environment were conducted in the I'.S.A. and 
various European countries before release of the Compo- 
nent Monitoring System to assess its usability and to test 
specific monitor functionality. With each Component Mon- 
itoring System release, further line tuning of ease-of-use 
aspects has been done, but the main operating concepts 
have proved sound. 

Designing for Ease of Use 

To ensure intuitiveness and ease of use, a number of de- 
sign decisions were made for the human interface of the 
Component Monitoring System. These are discussed in 
the following paragraphs, 



Intuitive and Explicit Labeling The human interface always 
uses verb+noun combinations as softkey labels (Change 
Lead, Adjust Alarms, Select Parameter). It always uses nouns or 
objects for functional entries on Lite keypad ( Parameters, 
Patient Data, Monitoring Procedures). 

In the past each front-panel control had one function, 
which needed a label for explanation. To keep the prod- 
uct's appearance unconfusing. it was necessary to abbre- 
viate labels. This made them hard to interpret and to lo- 
calize. The function of a key is much clearer if both a 
verb and a noun are part of the label. Then the control 
clearly does "something to something". 

All function keys act only as softkeys — they don't have an 
additional meaning as a hardkey. There is always only 
one function assigned to a given control. There are no 
hidden functions and no automatic screen actions, which 
are perceived as unexpected, are not obvious to the user, 
and require extra training effort. 

Task Window Appearance. All task windows or setup 
menus have the same layout and appear in the same posi- 
tion on the monitor's screen. All information needed to 
perform a given task is included in this window. The win- 
dow height is a function of the amount of information 
that has to be presented. However, the basic design goal 
was to keep these windows as small as possible to mini- 
mize the amount of screen they cover. 

Screen Eye Movement. The most critical information, such 
as patient alarms, is placed on the top right side of the 
screen. Because the vital sign numerics are critical for 
the patient status assessment, they always appear on the 
right side of the screen. Prompts and status messages are 
always shown in the top middle portion of the screen. 

Context Sensitive Help. The Component Monitoring System 
help function is intended to replace the traditional in- 
struction card. I'pon request (pressing the Help hardkey) 
the system provides one or two lines of information 
about the functionality of (he currently activated softkey 
or choice. In the case of mullistep procedures a more 
detailed description of the procedure steps is shown as 
permanent help inside the operating window. None of the 
help components hides the currently active task window. 

Consistency. This issue is critical for the ease of use of 
the monitor. The same functions are kept on equivalent 
keys across different operating windows (e.g., the Adjust 
Alarms function is always the rightmost softkey in any 
parameter task window). The same wording is used for a 
function that appears in several windows (e.g.. Change 
Scale is used as a softkey label whenever a change in a 
parameter's amplitude is implemented). All softkey labels 
are printed with an initial uppercase character followed 
by lowercase letters. Highlighting is always used to indi- 
cate that a given field is currently active. Blinking is al- 
ways used to indicate that an alarm condition is present. 
Operating the monitor from the screen bezel or the re- 
mote keypad is the same. All bezel keys appear in the 
same layout on the remote keypad. Rules and guidelines 
ensure that application software modules present task 
windows in a consistent way. This applies not only to the 
run-time task windows but also to all parameter configu- 
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ration windows. All have similar appearances and identi- 
cal controls. 

Color. Color is additional and redundant and never used 
as the only coding scheme. Color is used basically to dif- 
ferentiate real-time waveforms displayed in an overlapping 
fashion. Weces of information that belong to one parame- 
ter source (such as the real-time waveform, numerics, and 
the trend wave) always liave the same color. All operating 
windows have the same color (cyan) and all softkey la- 
bels are white on cyan. Alarm severity is expressed in the 
colors of the alert messages. Life-tlirealening alarms are 
in red, caution or warning alarms are in yellow, and inop- 
eraiive conditions are shown as green messages. A red 
X-bell symbol is used throughout the system to indicate 
that alarms are turned off. 

Avoiding Operating Errors. All choices for a given function 
are always shown. There are no hidden choices. The sta- 
tus of a given setting is shown before a change is initi- 
ated. Prompt messages and prompt sounds are used to 
inform the user if an action cannot be executed properly. 
Actions like pressing Confirm or finishing multistep proce- 
dures (e.g., zeroing a pressure line) always result in a 
prompt message and sound. 

Graphics. In addition to digital readouts, graphic elements 
are widely used. This includes size bars for amplitude 
adjustments and audible volume control and alarm ami 
value bars to indicate the current range of alarm limits. 

User Defaults and Configuration Sets. The basic design goal 
is that it be possible to turn on the monitor, attach the 
transducers and electrodes to the patient, and start moni- 
toring without any farther settings or adjustments. This 
means that the monitor will initiate at power-on with a 
set of user-definable settings. These user defaults can be 
specified at installation time and changed whenever re- 
quired. They are stored in nonvolatile memory and read 
after monitor restart. This applies to every parameter 
module in the Component Monitoring System. 

In addition, a whole set of user settings related to one 
specific Component Monitoring System element, such as 
the display or the recorder configuration, can be bundled 
together ;uid accessed by a single keypush. For example, 
all screen related attributes, such as waveform assign- 
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ment to display channels, number of waveforms, speed of 
waveforms, and overlapping formats, can be put together 
as one screen choice. Up to three different screen 
choices can be stored in nonvolatile memory. This sup- 
ports applications in the operating room, where depend- 
ing on the course of surgery, specific screen layouts have 
to be accessible without complex interaction. 

Finally, the c oncept of a configuration set supports the 
monitor's ease of use and flexibility by customizing the 
parameter algorithm behavior and the parameter settings 
according to the specific environment (operating room or 
ICU) or to the patient's age (adult, pediatric, or neonate). 
The user can specify or change the monitor's behavior 
simply by selecting one of the four available configuration 
sets prestored in the monitor. This again simplifies the 
monitor's setup in an environment like the operating 
room, where patients of different ages undergo surgical 
interventions. 

The Resting Display 

The resting display is what the Component Monitoring 
System shows when no user interaction is taking place. 
Fig. 3 shows a typical resting display. 

Since the monitor's main task is to measure a patient's 
vital signs and give an alarm if a critical situation occurs, 
the top line is reserved for alarm information. It also con- 
tains the patient's name, the current date and time, and 
the basic configuration of the monitor — for example, a 
classification of the patient and the application area for 
which the internal algorithms are optimized. 

The next line contains status and prompt messages in- 
forming the user about events that are not as critical as 
alarms, but give information about such things as suc- 
cessfully finished recordings or parameter calibration pro- 
cedures. 

Depending on the Component Monitoring System configu- 
ration and the user's choice, the resting display shows 
four, six, or eight real-time waveforms of the measured 
parameters with the digital values derived from the wave- 
forms displayed next to them. For better vertical wave- 
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form resolution, up to two groups of waves can share a 
larger sector on the screen. This overlapping of wave- 
forms allows the user lo correlate differeni waveforms on 
the lime axis. 

Each waveform channel can he assigned a different 
speed. Two presentation modes of Ihe waveforms are 
possible: either the waveforms are fixed on Ihe screen 
anil old waveform samples are erased by Ihe newest, or 
Ihe waveforms move across the screen with the newesl 
samples always next to the digital values. 

The conlent of each channel can lie configured. Addition 
ally, the user has Ihe choice of three prcconfigured 
screens to make it possible to adapt quickly to changes 
of the patient's condition. 

Digital .Values 

The user has definite expectations about where, when, 
and in what formal digital values should appear. The re- 
quirements for Ihe arrangement of the digital values were: 

• The values of a parameter plugged into a rack or turned 
on should show up automatically. H is unacceptable to 
have to position Ihe value of such a parameter manually, 
It must appear in Ihe right position. 

■ The digilal values must be placed nexl to their corre- 
sponding waveform if possible. 

• As many values as possible have to be shown with large 
digits. ( in a lull display it is acceptable for the less -impor- 
tant values to be shown with small digits, but not on a 
display with just I wo measured parameters. 

These requirements are met by an elaborate algorithm. It 
is an iterative process that tries to find a place for all 
digilal values available in Ihe system. It first places all 
values next to their waveforms With large digits. It then 
places all other values, according lo a priority list, in the 
right column next lo the waveform values. Temperature 
values are first assigned large digits. 

If there are slill unassigncd numerics left but no more 
space available, Ihe algorithm starts decreasing values in 
size, stalling with those of lowest priority, ami repeats 
the process. As a last resort, temperature values are al- 
lowed to share Ihe same place, alternating at two-second 
intervals. 

Operating Concept 

The general operating structure of the Component Moni- 
toring System human interface is described by the state 
diagram shown in Fig. 4. 



Keypad. After the keys on the parameter modules, which 
are mainly used lo enter the menus and a<Uusl parameter 
settings, Ihe keypad underneath Ihe screen is the main 
tool for users to interact with Ihe monitor. Fig. 5 shows 
this keypad. As mentioned above, a handheld keypad for 
remote operalion has some additional functions available. 

The first row of keys on the keypad Consists or seven 
function keys. Their functions are defined by the menus 
thai appear on Ihe screen. 

The nexl row of keys is used to enter six differeni cate- 
gories of monitor interaclion. 

The lowest row contains keys that immediately start ac- 
tions that are frequently used in the hospital's daily rou- 
tine. The Standard Display key always returns control lo the 
resting display. 

The Silence/Reset key is used to silence or reset alarms. 
The Suspend key is used to suspend or activate instrument 
alarm capability. There arc alarm-indicating LEDs on the 
left and a diamond of four cursor keys anil a Confirm key 
on Ihe far right The last group of keys gets highlighted if 
I hey can be used. 

The Array of Choices, If one of the keys in ihe middle row 
is pressed, the user iinmedialely gets a display of all of 
the interactions that belong to the category described on 
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the entry key (see Fig. 6). There are no hidden functions 
that the user might remember but does not know where 
to look for. 

Behind some of the entry keys there ran be more than 
seven functions. Thus the user is shown an array of 
choices with up to four possible lines of soft keys. The 
number of entries depends on the category and Ihe con- 
figuration of the Component Monitoring System. The ac- 
tive line is shown in full intensity. It can be moved up 
and down either by a»peatedly pressing the entry key or 
with the cursor keys. 

The array of choices illustrates three important mecha- 
nisms that occur consistently throughout the operating 
concept. 

• Resources, such as the place occupied by the array of 
choices, are used according CO Ihe system configuration. 

• Selected items are shown in lull inlensity 

• Two methods are consistently allowed for selecting an 
item: either by repeatedly pressing Ihe key thai was used 
to enter the context, or by using the cursor keys. Usabil- 
ity testing has shown thai I here are personal preferences 
for either method depending on the user's background. As 
a third method, touch would not clash with the operating 
structures, although it is not offered at this time. Inverse 
areas in half intensity could be activated by touch. 
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Fig. 7. The generic layout <>f a l;isk window. 

Task Windows. The array of choices is an intermediate 
step iti entering the next operating level, the task window 
Fig. 7 shows the generic layout of a task window. The 
possible functions are labeled with inverse soft keys, 
which do not change in this context. The currently active 
function is highlighted and linked to Ihe interactive area 
abOVe, which can contain items lo be selected or special 
contents needed for this specific softkey. 
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The status area underneath the title contains all status 
informal ion about the current task — including a real lime 
waveform if available — to make sure that the user does 
not have to select a [unction just to gel more informa- 
tion. The user only needs to press a softkey if something 
is to be changed. 

If required, the rightmost softkey can be used to jump 
back and forth to a subsequent task window. As an exam- 
ple, Fig. 8 shows an overview of the operating levels for 
three parameter setups. 

Human Interface Software Architecture 

The human interface software is embedded in the overall 
Component Monitoring System software architecture. It is 
one of the large data sinks that make intensive use of the 
communication model with its message passing concept. 
The well-structured information provided, for example, by 
the standard parameter interface (see article, page 19) 
makes it possible to add new parameters with virtually no 
changes to the human interface software. Il also allows 
resources to be used very effectively by allocating 
memory depending on the number of messages to be pro- 
cessed. 

Pig. 9 shows the layered structure of the human interface 
soi l ware module. Each parameter module, even a new 
one, broadcasts its standard parameter interface messages 
and is automatically recognized by the screen configura- 
tion software. To get a task window, any application soft- 
ware module either applies directly to the task window 
arbiter or specifies an entry in the array of choices. If 
selected, the array of choices manager arranges a dynam- 
ic link between the parameter module and the task win- 
dow arbiter. 

Any application software module can present information 
in a task window by using a command language that sup- 



ports the specific elements of the human interface, This 
is an effective way to achieve the required consistency 
across all task windows. The content of the task windows 
is determined by the application, but human interface 
related definitions are coded in the command language. 
Thus, most changes affecting the human interface design 
have to be done in the human interface software only. 

A powerful standardized keyhandler builds the interface 
between the application software and the task window 
command language. The command language hides the 
pixel coordinates of the display controller from the appli- 
cation software. Thus, the application software does not 
have to be changed in case the display technology 
changes, for example to LCI). The coordinate system of 
I lie task window command language is the same as was 
used during the human interface screen simulation. 

There are asynchronous FIFO buffers in the path between 
the task window commands and the connected hardware 
devices, mainly the display controller. A special hand- 
shake mechanism based on the monitoring of token mes- 
sages guarantees that the FIFOs cannot be flooded in 
peak situations. 

By setting up the human interface module two or more 
times in the monitor configuration lable (see article, page 
13) and plugging more display controller cards into the 
computer module, several independent displays can be 
connected to one Component Monitoring System. 
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Globalization Tools and Processes in 
the HP Component Monitoring System 

Software design and localization are decoupled. All languages are treated 
in the same way. A database contains the text strings for all languages, 
and automated tools aid the translator. 

by Gerhard Hvig 



The HP Component Monitoring System is an international 
product designed for a worldwide market. Among the 
requirements for the product were introduction of local- 
ized versions simultaneously with the shipment of the 
standard product, full Asian language support, and low 
incremental effort for localization in any new language. 

At first release, the product was localized in the following 
languages: English, German, French. Dutch, Swedish. Ital- 
ian, and Spanish. A Kanji/Kana prototype version was 
available as well. The current release is also localized in 
Danish, traditional Chinese, and simplified Chinese. 

Localization Goals 

To fulfill I he requirements, a number of goals were set 
forth very clearly in the design phase of the Component 
Monitoring System software. The major goals were the 
decentralization of localization efforts, the automation of 
the localization process, and the standardization of inler- 

faees. 

Decentralization. Decoupling Che software design and im- 
plementation process (R&D responsibility) from the local- 
ization process (technical marketing responsibility) makes 
it possible to produce a localized Component Monitoring 
System without interrupting the software engineers work- 
ing on their software modules. The coordination and lim- 
ing of the translations are not direclly coupled with the 
si il l ware development process. 

Automation. Automated processes to generate localized 
Component Monitoring Sysiem software allow efficient 
generation of localized versions whenever they are need- 
ed, especially in prerelease phases (regulatory approval, 
clinical trials, demonstrations, etc.). The automated pro- 
cesses transform all Component Monitoring System text 
Strings from plain English to the equivalent hexadecimal 

character representation. Automatic format checking is 

pari of this process. Translation of all text si rings of a 
Component Monitoring System software release in a 
single pass improves the consistency of the translated 
text — similar terms are translated the same way in vari- 
ous places. The same translator is responsible for text 
strings and for the Operating Guide translation. 

Standardization. A well -structured native language support 
(M.S) database is needed. The generation process for 
localized software and the translation process are the 



clients of this database. The NLS database is part of the 
Component Monitoring System software maintenance sys- 
tem. 

Simple and standardized interfaces between the compo- 
nents of the localizat ion process are necessary. This in- 
cludes common file formats for the NLS database, com- 
mon tools for accessing and handling text strings, and 
common tools and processes to translate and generate 
localized software. 

Design Decisions 

Specific design decisions had to be made to achieve these 
goals. Among these are: 

• The HP standard Romans character set is supported. This 
allows localization of up to 14 Western European lan- 
guages with one RomanS character generator, which is 
located on the display controller function card. This con- 
siderably simplifies the handling of European language 
options. 

• All character codes are two-byte codes. Thus all text 
strings use two-byte character codes. This allows support 
of Asian languages as well as all European languages in a 
consistent way. Eor RomanS characters, the upper (un- 
used) byte is cleared. 

• A given text siring has a fixed field length across all lan- 
guages. Thus the field length of a given text string is not 
language dependent and the access of a soft ware module 
to its lext Strings is language independent In addition, all 
text strings are terminated with an end-of-slring charac- 
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ter. There is no language dependency in the way strings 
are handled in different languages. 
> Tcxi strings are separaled from module code. All soft- 
ware modules are language independent. Inside each soft- 
ware module, all (ext strings are located in TEXT directo- 
ries, thus being separaled from the code (PROG) directory. 
( hanging lexl sitings from one language to another does 
not affecl Ihe Component Monitoring System code. No 
recompilalion of ihe software is necessary' when a new 
localized Component Monitoring System version is pro- 
duced. 

• Standard HI'Ki codes for all Asian languages are sup- 
ported. This allows the Component Monitoring System to 
handle all Asian languages identically and supports the 
c onnection of Asian printers as well. For each Asian lan- 
guage, a specific .Asian EPROM card with Ihe complete 
font set is supported. 

The standard character cell supports all Asian language 
fonts. The standard character cell is l(i pixels wide by 211 
pixels high. The Asian fouls (Kanji/Kana, Chinese) are 
handled as right-justified l- r )-hy-16-pixel characters (see 
Fig. 1). 

A pixel is 0.219 mm wide by 0.352 mm high, giving an 
aspect ratio of 1.6. An Asian character should have a 
square appearance, so the display controller firmware 
doubles each pixel in Ihe x dimension. This means that a 
Kanji character takes twice as much space in a horizontal 
string as a KomunK character. Since each Kanji character 
occupies two Mental character cells, all Asian sitings are 
limited to half Ihe lenglh of RomanS character sitings. 
The Asian translation tool takes this restriction into con- 
sideration. Fig. 2 shows the traditional Chinese translation 
of a typical Component Monitoring System task window. 

The NLS Database 

The NLS database contains all strings thai are visible to 
Ihe Component Monitoring System user. They show up 
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Fifi. 3. MLS database structure. 

mainly on Ihe screen, but may also be present on the 
keypad and the patient parameter module panels. 

The database is organized under Ihe lll'-l 'X file system as 
hierarchical file directories (see Fig. 3). The database is an 
integral part of the Component Monitoring System docu- 
mentation and is maintained with Ihe HP-UX res utility. 

Below the main entry, a distinct entry called a LANG(uage) 
tree is provided for each language. There is a basic direc- 
tory where all localizable strings are stored in plain En- 
glish. This is the RAW directory. Its structure is identical 
to all of the LANG Irees but it is not known to Ihe transla- 
tion tool and to the lext compiler. Whenever text strings 
are added, deleted, or changed, this directory must be 
updated. 

The LANG trees are organized as a collection of valid NLS 
revisions, such as ENG/ENG6.I or GER/GER6.2. The Knglish 
revision is the starting poinl for all farther translation 
activities. All LANG trees have an identical structure and 
are composed of a collection of NLS entiies such as ECG, 
PRESS, and so on. Each software module has one NLS 
entry in Ihe database. Keeping all text sitings of one soft- 
ware module together eases and improves the translation 
of the lext strings of that module. 

Each NLS database entry contains a set of NLS files I hat 
incorporate the text strings. A standard file formal is es- 
lablished for all NLS files (see Fig. 4a). Il is processed by 
the NLS tools and recognized by Ihe translation tool. NLS 
files contain title, header, context, and text sections. The 
title section contains the pathname, language, and revi- 
sion of the NLS file. The header section is a list of formal 
specifications, such as sz for string size or ic for initial 
caps, which are read by the hexpander tool (see below). 
In Ihe context section, advisory information is given to 
the translator to make translation of that NLS file easier. 
It is read only by the translation tool. The texl section is 
Ihe body of the NLS file. It contains a sequence of items, 
each item identified by a text code and a lext string. 



Fig. 2. Traditional Chinese translation 01 the pressure calibration 
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NLS Tools 

The hexpander and the syntax Checker are used to gener- 
ate and check the hexadecimal character strings in the 
ENG directory. The text compiler interfaces the NLS data- 
base to the C source code. Fig. 5 shows how the NLS 
tools interact with the NLS database. 

The hexpander takes the plain English texi from the RAW 
directory and generates the hexadecimal character strings 
in the ENG directory according to the format sjiecifications 
(see Fig. 4b). A utility called make_hexpand automates the 
process of generating and checking the syntax of the hex- 
panded ENG strings. 

The syntax checker reads the hexpanded files and flags 
syntactically incorrect strings (e.g.. too long). A similar 
checker is incorporated into the translation tool to check 
the hexpanded ENG NLS file before translation takes 
place. 

The text compiler links the C source code with the NLS 
database, which contains text strings collected in files. 
References to these files inc lude the language, the module 
entry (such as ECG or HEART), and the specific file contain- 
ing a given class of text strings (such as SK_LABEL or 
ALERT). Fig. 4 shows an example or the ECG/SK_LABEL text 
file. 

In the TEXT directory, the programmer specifies a source 
file (of class .txt) which conlains the references to the 
NLS files, such as IECG/SK.LABEL 2.1 The txt file is identical 
to the c file except that it has the NLS file references, 
(preceded by the escape character I), which mast be 
resolved before the Tile can be compiled (using make). The 

Title 'CMS TEXT FILE ECG SIL LABEL 

language. ENG 
SRivluon: IS } 

SSource: uteri cmi nl» flAW ECG ACS SKAABEL.vS 
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Fig. 5. MLS tools. 

text compiler resolves these references. It reads lite hex- 
panded NLS file (Fig. 4b). extracts the hexadecimal equiv- 
alents of the referenced text strings, and replaces the 
NLS file references in lite ixt file with these sitings. The 
output is the (' source file (or class .c). 

Thus, the text compiler is simply a preprocessor that 
lakes care of the text strings. The programmer of the 
software module does not have to know what hexadeci- 
mal strings ate ultimately loaded into the c Tile. This is 
language dependent and does not affect the c code. 

To automate this process, the make Jang utility was estab- 
lished. This utility is a script that executes the lexi com- 
piler for every software module that conlains references 
to localizablc lexl strings. The text compiler resolves 
these references by inserting in the indicated places in 
the txt files the hexadecimal equivalents of lite lexl 
Sitings. The output c Tile is then compiled by the make 
Utility iii I he usual way. An example of calling the 
make Jang Utility is: 

make Jang "NLSREV=7 2" "LANG=ENG" 
Localization Process 

The process established to implement the localization 
activities is shown in Fig. 6. 

R&D is responsible for the generation and maintenance "I 
the NLS database and (he RAW and ENG language lives. 
The chcckcd-in ENG revision is the starting point for all 
translations. This ENG tree is provided to the technical 
marketing group together with a della list containing all 
changes front the previous ENG revision. This group is 
responsible for driving and coordinating the translation 
process. When this process is complete, the translated 
LANG tree is loaded back into (he NLS database. Auto- 
mated utilities such as make cms are used in R&D to gen- 
erate the localized Compouenl Monitoring System soil- 
ware. R&D is responsible for providing the EPROM cards 
wilh I he localized software. A quality assurance cycle 

similar to thai for the eng version is then started fox each 
localized version. Fan of the QA process is a cmsfstencj 
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Fig. 6. The localization process. 

and wording check of the localized software. The lan- 
guage verification is scheduled and coordinated by techni- 
cal marketing. The same translator who did the Compo- 
nent Monitoring System translations is assigned to 
language verification or the Component Monitoring Sys- 
tem product 

Translation Tool 

The localization goals could not have been achieved with- 
out a powerful and versatile translation tool. Because 
nothing was available off the shelf, we had to write our 
own. The tool is personal-computer-based, thus allowing 
translations of the Component Monitoring System text 
strings in each local IIP office. The tool supports 16-bit 
character codes. It handles the standard RomanS charac- 



ter set and allows printing of the translated strings on a 
IIP LaserJet printer. 

The tool is designed to facilitate translations of large 
quantities of text. The tool reads the English source files 
and presents the translator with the destination fields for 
the translated strings, which are then written to the re- 
spective LANG tree. 

Translation is possible for a complete LANG entry, for spe- 
cific NLS entries (e.g., all strings of the ECG software 
module), or for specific text files inside one NLS entry. 
Printouts can be made from each of these translation 
levels. The user interface is soft key driven. 

Presently, this tool is used throughout the IIP Medical 
Products Group and is supported by the CAD/productivity 
group at the Boblingen Medical Division. It allows effi- 
cient translations with a clear, standard interface to the 
NLS database and the Component Monitoring System soft- 
ware development group. Its major benefit and achieve- 
ment is the separation of translation activities from the 
software development efforts. 
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The Physiological Calculation 
Application in the HP Component 
Monitoring System 

This application converts raw real-time data into derived values the 
clinician can use to assess the patient's hemodynamic, oxygenation, and 
ventilatory condition. 

by Steven J. Weisner and Paul Johnson 



The IIP Component Monitoring System bedside monitor 
provides the clinician with a variety of \ital-sign parame- 
ters such as heart rate and respiration rate. These raw 



values and the associated alarms are very important in 
monitoring the patient. However, the human body is not a 
collection of independent physiological systems. Rather, 
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ail major body systems interact in a variety of ways, 
many of which can be calculated by combining the raw 
parameter values into meaningful indicators. 

Physiological calculations are used routinely by many- 
hospitals as part of their normal assessment and rec- 
ord-keeping process. Calculations provide a way of quick- 
ly reducing a large number of variables into a single num- 
ber that represents a comprehensive physiological 
function. For example, to measure the load applied to the 
left ventricular heart muscle during the period of the 
heartbeat when the blood is ejected from the heart into 
the rest of the body (ventricular ejection), a variable 
called systemic vascular resistance (SVR) can be calcu- 
lated from measurements of the mean arterial blood pres- 
sure (ABPm), central venous pressure (CVP). and cardiac 
output (CO). 1 

Studies have shown that calculated values such as pulmo- 
nary vascular resistance (PVR) and left and right cardiac 
work (LCW/RCW) are good predictors of major malfunc- 
tions or mortality in intensive care patients. 2 Other stu- 
dies have validated the efficiency of using calculations 
such as stroke index (SI) and left and right ventricular 
stroke work (LVSW/RVSW) for preoperative assessment of 
unacceptable risks for major surgery. 3 

The Typical Calculation 

Poiseuille's law describes the laminar, constant flow of 
Newtonian liquids through rigid cylindrical tubes. Accord- 
ing to this law, the ratio of pressure drop to the rale of 
flow is a function of all of the forces that retard this flow 
(i.e., radius, length, and viscosity). Blood does behave as 
a Newtonian fluid in blood vessels that are greater than 
0J5 nun in diameter. Blood How through these vessels is 
generally laminar, although the arterial tree exhibits more 
pulsatile behavior. Although blood vessel radii do vary 
slighlly because of the applied pressure of the blood, Poi- 
seuille's law can be used to calculate a first-order approx- 
imation of resistance by applying Ohm's law for electrical 
circuits. 

Just as resistance in a circuit is equal to the voltage dif- 
ference divided by the current flow, vascular resistance 
(R) can be approximated by dividing the pressure differ- 
ence between the inlet of the vascular bed (PI) and the 
outlet of the bed (P2) by the blood flow (Q). 

R = (PI - P2)/Q. 

In medical terms, we measure the difference between the 
mean arterial (ABPm) and venous (C VP) pressures ami 
divide by the cardiac output (CO). The resultant value is 
converted from units of mtiiHg/l to units of dyne-s/cm 3 by 
multiplying times 79.97. This value is called systemic vas- 
cular resistance (SVR). 

SVR = 79.97(ABPm - CVPyCO. 

With this value, the clinician can get a measure of the 
constriction of blood vessels (vasoconstriction) or expan- 
sion of the blood vessels (vasodilation). Changes in SVR 
are related to oilier cardiac failures such as hypovolemic 
shock, left ventricular failure, cardiogenic shock, and hy- 
poxemia 1 



Other calculations used to assess the state of the cardio- 
vascular system are shown in Fig. L 

The two pressure measurements ABP and CVP are ac- 
quired through invasive pressure catheters attached to the 
patient and monitored through the Component Monitoring 
System parameter modules. The cardiac output parameter 
is obtained through a CO parameter module and mea- 
sured using a monitoring procedure, which requires the 
clinician to interact with the Component Monitoring Sys- 
tem. The acquisition of the output value (SVR in this 
case) and the presentation of the calculations to the clini- 
cian are described in the following sections. 

Data Management Package 

The calculations package in the Component Monitoring 
System is a subset of a more general data management 
package. This package consists of seven Component Mon- 
itoring System application software modules, as shown in 
Fig. 2. The data acquisition module acquires and averages 
raw parameter data (e.g., heart rate) over a one-minute 
period. This raw data is available as a broadcast message 
on the Component Monitoring System's internal message 
passing bus. The one-minute-average data is stored in a 
buffered RAM database. The database module provides 24 
hours of data storage for 16 continuously monitored pa- 
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WT - Body Weight in g 

HT - Body Height in cm 

HR - Heart Rate in beats min 

CO - Cardiac Output In I min 

ABPm - Arterial Blood Pressure Mean in mmHg 

CVP - Central Venous Pressure in mmHg 

PAPm - Pulmonary Arterial Pressure Mean In mmHg 

PAWP - Pulmonary Arterial Wedge Pressure in mmHg 

KiK- 1. Hemodynamic calculations performed by the calculation 
evaluator module of the I ^ompnnenl Monitoring System data man- 
agement software package 
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ramctcrs with one-minute resolution. Parameters that are 
measured intermittently or as part of a procedure, such 
as noninvasive blood pressure or cardiac output, are re- 
ferred to as aperiodic- parameters. The database module 
allows storage of 3(i aperiodic parameters, each Contain- 
ing up to !t(i measurement points. All retrieval of the data 
is mediated by request messages and return-data mes- 
sages sent across the message passing bus. 

The acquired data can be presented in four forms. A tab- 
ular data display (UPC_TABULAR) presents 13 rows of pa- 
rameters in eight columns of time. A graphic trends dis- 
play (UPC TRENDS) shows up to nine parameters in graphic 
form on three separate axes. Calculations are done by 
two modules: the calculation cvaluator (CALC). which per- 
forms the calculations, and the presentation module 
(UPC_CALC), which provides the user interaction with he- 
modynamic, oxygenation, and ventilation calculations. The 
clinician can also review the calculated data as a function 
of time in a tabular format 

Finally, there is a report package, which provides printed 
copies of any of the tabular, trends, or calculation dis- 
plays. This report is preformalted and can be printed lo- 
cally at the bedside or remotely on a central printer. 

Calculation Evaluator 

The calculation evaluator module (CALC) is a collection of 
services associated with physiological calculations. These 
services are invoked by means of messages sent to the 
CALC module. Typically, applications such as UPC_CALC in- 
voke the functions of acquiring the appropriate reference 
time and input parameters for the calculation and then 
calculating the output values. 

In addition, the CALC module provides a separate service 
to calculate the body surface area (BSA), which is used 
as a common index for many physiological calculations, 
and is also used outside of the data management package 
by the cardiac output module. 



Calculation Presentation 

The clinician obtains the services of the calculation evalu- 
ator through the user presentation module of the calcula- 
tions soft ware, UPC CALC. UPC_CALC is a single Component 
Monitoring System application that provides access to 
both calculation entry and calculation review frames. 

The first step in performing physiological calculations is 
for the clinician to select a physiological calculations 
group from the set of predefined options: hemodynamics, 
oxygenation, and ventilation. This is accomplished by se- 
lecting the appropriate entry key in the Patient Data array 
of choices. Once this is done, the Component Monitoring 
System human interface software establishes a link be- 
tween UPC_CALC and the monitor display. The calculation 
entry frame is shown in Fig, 3. 

After the calculation group has been selected, the clini- 
cian can then perform one or more of the following ac- 
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lions by using the labeled softkeys and a remote keypad 

for alphanumeric entry: 

Select a calculation time 

Enter or edit input parameters 

Calculate output parameter values 

Display alternate parameter attributes 

Print a report of the calculations. 

UPC.CALC uses the measurement lime of Hie principal in 
put parameter as the reference time for all calculations. 
In the case of hemodynamic calculations, shown in Fin. :t. 
(lie cardiac output parameter drives ail of the other calcu- 
lations. Thus the time of the lasi CO measurement is 
used as a reference. All other input parameters used in 
the calculations are retrieved from the data management 
package database through a CALC module service, based 
on that reference time. The clinician can choose to over- 
ride this lime by using the Change Time key to select a ilif 
ferenl reference time. 

Not all input parameters used to perform calculations are 
automatically acquired by the Component Monitoring Sys- 
tem. By using the remote alphanumeric keypad, the clini- 
cian can enter a numeric value for any of the input pa- 
rameters. The clinician can also override an automatically 
acquired parameter simply by entering a new value. All of 
these manually entered values are stored in the database 
and are used in subsequent calculations. 

Once all the necessary calculation time and input paraine 
ler changes have been made, the clinician can request 



calculations of the output parameter values. UPC_CALC 
sends a request to calculate the output values tn the CALC 
module, which performs the appropriate calculations. CALC 
then sends a return message back to UPC.CALC containing 
the list of output parameter values, labels, normal ranges, 
and measurement units. UPC_CALC uses this information to 
show the output values on the Component Monitoring 
System display. 

The clinician may wish to compare the output values to 
the expected normal physiological ranges for these val- 
ues. When the ON/OF Ranges softkey is pressed. UPC_CALC 
toggles between showing the output parameter units and 
the normal ranges. 

UPC_CALC also serves as the presentation layer software 
for the calculations review frame. The review frame pre- 
sents the clinician with a tabular format of all previous 
calculations performed for this patient. As in the calcula- 
tions entry frame, the clinician can compare values 
against normal ranges and obtain a printed report, as 
shown in Fig. 4. Typically, this report might be included 
with the patient record to aid the clinician in assessing 
the patient's past and current physiological states. 

Conclusion 

The Component Monitoring System data management cal- 
culations package provides the clinician with a means of 
reducing the large volume of raw vital-signs data into a 
manageable set of variables. Measures of cardiovascular 
performance, blood oxygen content and delivery, and re- 
spiratory gas exchange can be obtained through the he- 
modynamic, oxygenation, and ventilation calculations. 
These calculations are vital to the clinical diagnosis and 
prognosis of the critically ill patient. 
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Mechanical Implementation of the HP 
Component Monitoring System 



The part count and the number of different parts are dramatically lower 
than for previous designs. Fewer than ten vendors are used for purchased 
mechanical parts. 

by Karl Daumiiller and Erwin Flachslander 



From the mechanical perspective, the- III' Component 
Monitoring System offered several challenges. Among the 
most important were the definition or the architecture of 
the computer module and the design of the sheet-metal 
and plastic parts Tor diis component. Other mechanical 
highlights include the implementation or the display front 
assembly and the construction of the parameter modules. 

Computer Module Chassis 

Th«' general design objective for the computer module 
was to create a flexible, compact instrument that could 
easily be extended and upgraded. In accordance with the 
modular concept of the Component Monitoring System, 
the computer module had to be designed so that the 
function cards could be handled as independent modules. 
All (unction cards were to be accessible without having 
to remove or disassemble major parts of the enclosure. 

From the production point of view, the following general 
design objectives had to be met: 
Minimum pan count 

Minimum number of parts with different slock numbers 
Minimum vendor count 
I 'se of preferred parts 



• Compliance with all relevant medical safely standards 

• Simple and automated assembly. 

We also committed ourselves to design an enclosure that 
could be assembled and serviced with only one tool (all 
you need is a screwdriver). 

The clinical environment mandates that the product be 
easily cleaned and have no sharp comers, sharp edges, or 
deep indentations. Liquid spilled over the Component 
Monitoring Syslcm is not allowed to create a hazardous 
Situation for the patient or the user, nor may il leak into 
the unit Last but not least, the constraints of the elec- 
tronics had to be taken into consideration. 

The requirements were sometimes contradictory. For ex- 
ample, on one hand, the chassis needs to have low HFI 
emissions, while on the oilier, il needs sufficient openings 
to dissipale as much heal as possible. The maximum in- 
ternal temperature rise cannot exceed 15°C. Heat manage- 
ment is made more difficult by the fact that fans are not 
acceptable in the moniloring environment. This implies 
ihat natural convection is the main mechanism for dissi- 
pating heal. 



DC-to-DC 




Fig. i. Exploded view of the com- 
puter module of the hp Compo- 



nent Monitoring System 
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Extensive measurements with simulated electronic circuits 
and calculations in the early project phase were a good 
basis for the architectural design of the computer module 
The knowledge gained from these studies and the demand 
for easy access to the function cards led to the present 
design. 

Product Design 

Two large sheet-metal parts form the enclosure of the 
computer module (see Fig. 1 ). The bottom part of the 
chassis is made of 1 25-mm-thick steel and has a large 
number of openings for ventilation. Mounting holes and 
pressed-in threads for the instruments feet and locking 
cam are located here. The inner pan of this I -shaped 
component has a number of indentations and cutouts. 
This construction allows the plastic guide for the function 
cards and the central plane to be snapped in place with- 
out any screws. 

The second large sheet-metal part is the top cover of the 
chassis. Offset bends similar to those in the bottom part 
of the chassis make it possible to snap the plastic func- 
tion card guide into the lid. Pressed-in threads are 
mounted on the offset flange to hold the function cards 
within the computer module. 

Two large indentations with strong steel strips riveted to 
the top cover provide a quick and easy way to mount the 
14-inch display on the Computer module should this be 
desired. A combination of indentations with an undercut, 
feet with noses, and the cam forms a light locking mech- 
anism between the display and the computer module. 
This technique was rust used by the HP Medical Products 
Group in 1!«1 Tor the HP S040A cardiolocograph. This 
well-established mechanical interlace for slacking instru- 
ments or attaching them to wall or ceiling mounts or 
carts was a must requirement 

After the U-shaped bottom cover and the lid of the Chas- 
sis have been assembled, all function cards can be in- 
serted by simply sliding them inlo the enclosure. Metal 
board covers mounted on the rear ends of Hie function 
cards seal the remaining openings of the computer mod- 




Fig. 2. inside the partially BaseinbJed ( ompwiw module 




Fig. 3 It. ilium view (if the computer module with unlatched internal 
rack and side and rear covers. 

ule. Each board cover contains openings for RFI clips 
and the function card's external connectors, and provides 
a mounting hole for fixing the function card to the frame. 
The remaining area is perforated for ventilation, except 
for the space needed to silk-screen the board name and 
number. Fig. 2 shows the interior of the computer module 
with the fund ion cards inserted. 

As described earlier, the function cards are held in place 
by plastic guides in the top and bottom parts of the chas- 
sis. The printed circuit board guide is an injection-molded 
part thai can be used in both locations by simply turning 
it over. 

After the lop cover is installed, the left and right side 
covers can be attached to the computer module. Again, a 
single injection-molded part fits both sirles. This pan con- 
tains all the vents and openings needed for thermal man- 
agement. The side covers also conceal the six screws thai 
attach the chassis lop to the bottom. The customer can 
easily remove the side covers for cleaning by unlatching 
the internal rack (see Fig. •!). 

For visual and cable management reasons, a rear cover 
was designed. This ituect ion-molded pari contains 
molded-on pivots and latching elements. Another injec- 
tion-molded part with magnetic strips glued on fills the 
indentations on the top cover when the instrument is in- 
stalled without a display on lop (see Fig. -1). This com- 
pletes the set of plastic parts for the computer module. 

The material used for all plastic parts except the chassis 
feci is Bayblend®, a polycarbonale/ARS blend. The chas- 
sis feet consist of Iwo components: a highly filled poly- 
amid for the body and a block copolymer for the inside 
element The cam is molded from polyacetate. 

Display Front Assembly 

Tlie Component Monitoring System can be equipped with 
a choice of displays. The basic models are 14-inch mono- 
chrome and color displays. These displays consist of two 
major components: the bezel or front assembly, and I he 
display consisting of the CRT, Ihe deflection electronics, 
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Fig. 4. Assembled computer module with Integral parameter module 

rack. 

anil the main power supply for 1 he Component Monitoring 
System (see Fig. 5). The latter pari is called the common 

unit 

The common unit is a purchased pari. To minimize [he 
number of options the vendor lias to build and supply, 
this pari of the display contains no language-specific ele- 
ments. All options, like local language, are restricted to 
the front assembly only. 

Objectives like design for inanufaclurabilily. clinical re- 
qufrernents similar to those for the computer module de- 
sign, and the limitations introduced by the electronic cir- 
cuits played an important role in the development of the 
Component Monitoring System displays. 



Fig. 5. Tin- display n.nsisls of the front assembly and the display 
itself. 

The front assembly consists of a lotal of ten parts, which 
can be assembled simply by snapping Hie components in 
place, 'fhe main element is the plastic band (see Fig. (i). 
This pari attaches to the common unit. Il also serves as a 
pickup frame for the bezel, the human interface printed 
circuit board, a power knob, and a protection cover. 

The protection cover, made of Ihermoformcd polycarho- 
nate, shields the human interface card from condensed 
waler or cleaning fluids, which might drip from the CRT 
screen onto the printed circuit board. 

The bezel is attached lo the band by snap-fit connectors 
and presses againsl the rim of (ho CRT. Since the mono- 
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chrome and color displays do not have the same screen 
curvature, two bezels had to bo designed. The bezel pro- 
vides room for a membrane keyboard, which is the main 
control panel of the patient monitor. This keyboard is 
based on a double-sided printed circuit board. The con- 
tact elements are metal domes of different sizes. They not 
only make contact when pressed, but also give a good 
tactile feedback. The domes are covered with an em- 
bossed polycarbonate polyester overlay, which has been 
silk-screened from the rear to prevent abrasion of the 
nomenclature. Currently, the membrane keyboard is avail- 
able in 11 different languages. 

Design Objectives for the Parameter Modules 

The parameter module mechanical design included the 
development of the plastic enclosure, the connectors, and 
the overlays and the mechanical part of the printed cir- 
cuit board design. Currently two module types exist: 
single-widlh and double-width (Fig. 7). The prime objec- 
tives for the design were that it be simple lo insert mod 
ules and pull them out of the rack, that the modules be 
rugged, and that the housing he compact, measuring only 
100 mm by 100 mm by 30 mm. In addition to the general 
mechanical objectives listed at the beginning of this ar- 
ticle, the parameter modules have to meet two special 
requirements. First, they must withstand a drop from a 
height of one meter onto a concrete floor. Second, for 
patient safety reasons, all connections lo the patient are 
electrically floating with respect to ground. This isolation 
between floating and nonlloating parts is tested at 1(5 kV 
and is implemented as part of the electronic circuit in 
each parameter module. 

From the electronic standpoint, two of the approaches to 
meel these objectives were to use surface mount technol- 
ogy for mounting the electronic components, and to apply 
new ways of assembling the printed circuit boards to 
achieve high packaging density. On the mechanical side, 
new ways had to be explored to build thin-walled iiyec- 
tion-molded parts that could withstand the mechanical 
and thermal stresses and still be durable enough for their 
long hard life in the clinical environment. The entire me- 
chanical design was done on the IIP ME HI system. Be- 
fore making the final molding tools, a large number of 
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modules were p remolded using aluminium tools. The ad- 
vantages were tliat tests could be conducted with 
close-to-final parts at an early stage in the project, and 
larger quantities could be built at a moderate cost for the 
extensive prototyping phase. 

Parameter Module Design 

The single-width parameter module consists of an assem- 
bly of seven parts (Fig. 8). These include five molded 
plastic parts for the enclosure, one front overlay, and one 
printed circuit assembly. The double-width module has 
two additional parts for the housing, and in the case of 
the noninvasive blood pressure module, a complete pump 
assembly, which is built in (see article, page 25). 

The plastic housing of the parameter module is divided 
into an outer enclosure and an inner frame. This is neces- 
sary lo provide the HVkV isolation between the floating 
and nonlloating grounds. Between the outer housing and 
the inner frame there is space for shielding material such 
as copper, mu-metal foil, or thin-walled steel sheet. So far, 
only the noninvasive blood pressure module has made 
use of this kind of shielding. 

The inner left and inner right frames are multipurpose 
parts for both module widths. The double-width module 
also has an additional middle part. 

To provide maximum volume within the modules, all plas- 
tic parts have very thin walls. Nevertheless, they have to 
survive a one-meter drop. They also have to be resistant 
to cleaning agents and disinfecting solutions. We have 
found that Bayblend meets all these requirements. Tltis 
compound includes both polycarbonate and ABS. Polycar- 
bonate improves the ruggedness of the material while 
ABS has a positive effect on the chemical resistance. 

The printed circuit assembly within the module consists 
of three boards: a digital board including the power con- 
verter, an analog board, and a board with LEDs and key- 
switches mounted on it. The three boards are intercon- 
nected by flexible layers soldered onto the boards. For 
component loading, soldering, and lest the three printed 
circuit boards are handled as one partially routed board 
with small bridges between the individual boards and an 
OUter frame lo hold all or the parts in place. Currently, 
we have nine parameter modules in production, which 
represent a total of three different routing contours. The 
overall size of the outer frame is identical for all parame- 
ter modules, thereby contributing to our standardization 
effort by making it possible lo use identical pickup 
frames for the different assembly stages. Al Ihe lasl stage 
of the production process the three printed circuit boards 
are broken apart, folded like a sandwich and inserted into 
the plastic enclosure. 

Additional mechanical parts thai were designed for Ihe 
parameter modules are Ihe patient cable, Ihe patient con- 
nector, and the module -lo-rack connector. The patient 
cable connector had to be compatible with HP's existing 
monitoring equipment One disadvantage of the existing 
system is the limited number of mechanical keys avail- 
able. For the Component Monitoring System we therefore 
redesigned Ihe connectors and extended the number of 
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possible keys so thai each parameter has a dedicated 
configuration. 

Module Assembly 

Assembly time for a single module is one minute. No 
screws or fasteners are needed-all pahs snap fit together. 
The normal assembly procedure includes the following 
steps: 

Fold the printed circuit boards together. 
Insert the printed circuit assembly into the left frame. 
Snap on the right frame (the inner module is now com- 
plete). 

Slide I he inner module into (he rear pari of the plastic 

parameter housing. 

Snap I he front and rear housings together 
Add the snap lock to the module. 

The module is now ready and waiting for shipment. In 
I he last production step, the proper language overlay is 
glued onto the front frame. 

Conclusions 

The mechanical design of the Component Monitoring Sys- 
tem meets all of the design objectives. The E-score (a 



Fig. 8. l-'xnlodcd view of a 
single-width parameter module. 

measure of ease of assembly) is a high 77 on a scale of 0 
to 10(1. Only one type of screw is needed for connections 
where good grounding or slabilily is required. Part num- 
ber and part count are dramatically reduced compared to 
former designs, and the total vendor count for all me- 
chanical parts is less than ten. 
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An Automated Test Environment for a 
Medical Patient Monitoring System 



The AUTOTEST program controls a keypusher and patient simulators to 
automate the testing of the software for the HP Component Monitoring 
System. 

by Dieter Goring 



The HI' Component Monitoring System is a completely 
new patient monitor. It is based on a dedicated operating 
system and has an integrated data management system. It 
Can process data from as many as 32 patient parameter 
modules and has an RS-232 interface Tor connecting a 
printer (see Fig. 1). 

Its alarm system has a very complex structure. There are 
three priorities: red. yellow, and green. There are alarm 
messages, sounds, and lights. Alarms can be Inrned on or 
off for all parameters or only selected ones. Alarms can 
be sent over the serial dislribution network lo central 
stations, arrhythmia computers, or other medical devices. 

Automated Test Environment 

The ideal test setup for the Component Monitoring Sys- 
tem was easy to define. We needed a Component Moni- 
toiing System patient monitor with all parameter modules 
installed, and we needed a human being medically con- 
nected to the monitor to (1) provide all of the patient 
signals such as heart rale, blood pressure, and so on. (2) 
change these signals to create alarm situations such as 
asystole or low blood pressure (it is said thai Tibetan 



monks c ould do this). (3) operate the monitor like a phy- 
sician or a nurse, (4) watch the monitor's display and 
verify correct operation (parameter numeric values, alarm 
messages), and (5) synchronously document all events. 

Our solution to these requirements is the AUTOTEST 
application (see Fig. 2). 

The AUTOTEST application controls programmable pa- 
tient signal simulators which play the role of a critically 
ill patient (items 1 and 2 above). It also controls a key- 
pusher, whic h can capture and execute keystrokes to op- 
erate the monitor (item 3 above). It cannot "watch" the 
monitor's display, but "takes a snapshot" of all important 
information (parameter numeric values, all alarm and in- 
operative messages) of the display's content whenever 
needed. All this information is sent over the serial distri- 
bution network every second (item 4 above). 

\( T( (TEST documents a test run completely into a proto- 
col file (item 5 above). This can prove that a certain test 
case has been run and that the unit has passed the test. 
This is important, because regulatory agencies may re- 
quest this data, even years after release. 




I'ig. i. HP Component Monitoring 
System with integrated parameter 
module rack 
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Fig. 2. The AUTOTKST .s,-i up for 
automat Pti Component Monitoring 
System testing. 



AUTOTEST Requirements 

The AITOTEST program requires an HP Vectra ES/12 
personal computer with enough disk space (or better, a 
large disk on a LAN server), serial and parallel interfaces, 
additional dual serial interfaces for the simulators, and an 
IIP 78301A serial distribution network interface. Also 
needed are an IIP Al 'TOMAN keypusher and at least two 
Dynatech 217A programmable patient signal simulators. 
These simulators are widely used in medical R&D, testing, 
and training. Two terminal ports on an IIP :J(M)0 computer 
are needed, one for the Vectra PC and one for the Al TO- 
MAN box. 

The software includes the AUTOTEST program package 
(written in C), AITOMAN software on the IIP 3000 com- 
puter, and a smart editor on the Vectra PC for reviewing 
the protocol files, which can be very large. 

The AUTOTEST Program 

AUTOTEST is a very simple but flexible application. It 
reads serially through an ASCII test file and executes 
each line as a command line The following are available: 
( ommands to control Dynatech or 01 her RS-2;!2-driven 
simulators connected to serial ports of the Vectra PC 
A command to send a keystroke file to the AUTOMAN 
application running on an IIP 3000 computer 
Commands to gel the monitor's data and optionally all 
alarm messages from the serial distribution network 
A command to pause the test (lets the tester read the in- 
structions) and wait for a comment or just a keystroke to 
continue 
Comment lines 

A "delay after" parameter (seconds) for every command. 

All commands, all comment lines, all data polled from the 
serial distribution network, and all keystrokes are echoed 
into a protocol file. The system time of the Vectra PC is 
also written into the protocol file before every command 
line. Fig. :? shows a test file and the corresponding proto- 
col file. 



Loops or branches are not permitted within a test file. 
However, for each test file it is possible to select the 
number of repetitions, and a batch feature allows queuing 
of test files in any combination. 

Any ASCII editor can be used for creating and maintain- 
ing test files. 

Test File Development 

The test files were developed in three Steps. First, we 
wrote high-level lest scripts based on the external refer- 
ence specifications, covering all of the functionality. Sec- 
ond, we gave these scripts to the R&D engineers for re- 
view. Third, we started development of the modular lest 
files, beginning with the most important ones (alarms and 
inoperative conditions) and those that are tedious to test 
manually. Tests were grouped into 100% automated tests, 
runs with a few manual interventions, sciniautoinated 
tests, and manual tests. 

The test files improved in effectiveness over time. Up- 
dates were performed constantly when new bugs were 
detected in the software being tested. 

When R&D had finished the implementation of all of the 
system's functionality, the development of all of the test 
files was also complete. Thus, for all of the defect -fixing 
rounds of testing, we ran almost exactly the same tests 
and could show very dearly the trend of the defect rate 
(see Fig. 4). 

Results 

With AUTOTEST, a test cycle now takes only seven work- 
ing days. A test cycle consists of 00 hours of automatic 
tests, mostly run overnight and on weekends. 45 hours of 
semiautomatic tests, and 5 hours of manual tests. There 
is also some destructive testing by selected experts, 
which is done in parallel with the systematic testing. Test 
documentation is complete when the testing is finished. 
The system provides a complete regression test package 
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Test file 
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-• bbbb tttlttBltttBttB tttttt it a aBBBBBtrttBtttt tttttt 
startup settings required: 
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Fig. 3. An example nfa u-.sl file and I he resulting protocol file. 



New Functionality Added 
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thai t an bp used for testing revisions and can hi 1 easily 
adapted to testing new parameters. 

We wrote one special test file that exercises Ihe Compo- 
nent Moniloring System with very fasl random keypush- 
ing. As long as lite software was not very stable, this test 
file caused Ihe sysiem lo crash fre(|tienily within a short 
period. With normal testing, we would have had lo wail 
weeks to see so many failures. The R&I) engineers liked 
litis lest very much because ii gave them a good chance 
lo (race (he software components and find Ihe causes of 
the crashes quickly, 

Conclusion 

Al'TOTKST is an excellenl example of an automated 
Structured lesling implementation, Kvcn though it seems 
lo he specially designed for Ihe Component Moniloring 
Sysiem. il is not. With some limitations (for example, no 
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keypushing) il can be used lor testing any HP patient 
monitor. It can be used simply for a form of guided test- 
ing in which AUTOTEST tells the test operator what to 
do and what the desired result is. and requests a key- 
stroke P for passed or F for failed. This makes il possible 



to have untrained people running the lests and still get 
complete documentation. AUTOTEST runs on an HP Vec- 
tra personal computer and is writlen in C, so it is porta- 
ble and can easily be modified or extended. 



Production and Final Test of the HP 
Component Monitoring System 

A vertically oriented material flow minimizes handling and simplifies 
customization. Automated final test systems minimize human errors and 
collect data for monitoring process quality. 

by Otto Schuster and Joachim Weller 



One of the keys to success in manufacturing a new prod- 
net is the concurrent design of the product and its pro- 
duction processes from the very beginning of a project. 
Therefore, a team of experienced manufacturing engineers 
was integrated into the IIP Component Monitoring System 
project and physically located in the R&D laboratory. In 
this way, product designs and production process designs 
were ahle to influence each oilier before all details had 
been worked out. 

The plan was also to transfer the product to production 
concurrently in Boblingen and in Walt ham, Massachusetts. 
Therefore, manufacturing engineers from Waltham joined 
our team to cover division-specific aspects and to ensure 
productive communication. 

Another key to the product's success was the definition 
of manufacturing goals to which all parties were com- 
mitted. The table below shows some of these goals and 
compares the Component Monitoring System with HP's 



previous generation of bedside monitors. 

TotaJ Part Number Count -67% 

Vendor Count for Mechanical Parts —17% 

Number of Printed Circuit Board Outlines -50% 

Autoloading Percentage +27% 

Manufacturing Cycle -50% 



Material Flow 

To reduce material in process and lo reduce manufactur- 
ing cycle time, it is essential to streamline processes 
without moving material back and forth. Therefore, we 
built up a vertically oriented material How. Products and 
assemblies can be built independently up In the point 
where they will be assigned to a customer order (see Fig, 
I). This is supported by a product Structure that allows 
assignment lo a customer order just before packaging. 
For example, the ECG modules are all built identically up 
to the last step, where the product is localized by apply- 
ing the overlay label in the appropriate language. 

Final Test 

The objectives for the final test systems were: 

• Flexibility to support different types of devices under 
test (Dl'T) withoul changing Ihe lest setup. 

• Use of standard hardware, or design and documentation 
of nonstandard hardware according to HP standards for 
manufad ured products. 

• Self-test and self-calibration features wherever possible 
to reduce maintenance. 

• Accuracy based on the specifications of standard instru- 
ments that are calibrated periodically. 
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A modular lost concept Iliat allows easy addition of new 
parameters, thai is. each type of parameter module has 
its individual software module for specifical ions, test list, 
test procedure. ;ind drivers. 

Ease of learning and operalion, even Tor relatively un- 
skilled personnel. This is achieved by a high degree of 
automation, which makes ii possible to operate the final 
(est systems with very little operator interaction. In addi- 
tion, color coding on the display for device types and 
stains messages and automatic recognition of the device 
under lest are implemenled. Instead of manual adjust- 
ments, calibration dala is generated by the final test sta- 
tion and stored in the El'Ut )M of the 1)1 T. To avoid hu- 
man errors, test results do not have to be interpreted by 

the operator. 

Dala accumulation for statistical process control 



Integration of Test Systems 

The final test systems are based on IIP 1HKJ0 Series 300 
Pascal workstations, muliiprograininers, diverse HP-IB 
(IEEE 488) instruments, and a parameter module inter- 
face, which provides the communication link between the 
1)1 T and the workstation. All systems are connected to a 
shared resource manager for sharing Ihe files required for 
operalion and archiving files containing lest results. This 
includes both the final lesl systems and the temperature 
cycling lest systems. 

An HP-UX workstation connected to the shared resource 
manager provides access to the files for other HIM X 
terminals on a local or wide area network (see Fig. 2). 
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Monitoring Process Quality 

To improve quality and keep it at a high level, it is impor- 
tant to analyze proc ess data online. Therefore, the lest 
results of the last 200 devices of each device type arc 
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held on disc for data analysis. Three different levels of 
information can be generated. The first level is the yield 
of printed circuit boards or modules. A diagram generated 
daily shows trends ami can be used as a trigger for a 
mole detailed analysis. This analysis represents the next 
level and includes failure summaries and failure hit lists 
for individual tests. The third level provides the distribu- 
tion curve for test results over the test limit range along 
with the following statistical process parameters (see Fig. 
3): mean, minimum and maximum values, standard devi- 
ation, Cp value (process capability), and Gpj, value (pro- 
cess controllability). 

This data is not only used for process monitoring. It has 
been used during Component Monitoring System prototyp- 
ing to qualify each lest and to verify the specification 
limits. Thus, early information about the producability of 
a new product is obtained well before the product is in- 
troduced into production and valuable feedback is pro- 
vided to the designers. 

Conclusion 

The challenge for manufacturing was not only that the 
Component Monitoring System was a new product, but 
also that it was our first product designed in surface 
mount technology and the first product for the Hoblingen 
surface mount technology center. The parallel ramp-up of 
production in Bohlingen and in Wallham has proven that 
concurrent production process design is not just an alter- 
native, but rather the only way to succeed. 
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Calculating the Real Cost of Software 
Defects 



Using data from a well-established software metrics database and an 
industry profit loss model, a method is developed that computes the real 
cost of dealing with software defects. 

by William T. Ward 



In response to the HP corporal e- wide 10 x software quali- 
ty iniprovemenl initiative, much attention has been fo- 
cused on improving the quality of software products de- 
veloped throughout IIP. The motivation lor software 
quality improvement is most often expressed in terms of 
increased customer satisfaction with higher product quali- 
ty, or more generally, as a need to position HP as a lead- 
er in quality software development. 

A more fundamental motivation to support the initiative 
for higher software quality can be developed when soft- 
ware defect cost data is considered. The data presented 
in this paper is drawn from an extensive software project 
database maintained at the IIP Waltham Division for prod- 
uct releases over the past five years. When software de- 
fect cost calculations are performed on this data, a very 
compelling "bottom line" perspective on software quality 
emerges; software defects are very expensive and early 
defect prevention and removal techniques can substantial- 
ly enhance the profit realized on software products. 

This paper will present a general model that can be used 
to calculate software defect cost data for any software or 
firmware product. Data from actual IIP Waltham projects 
will be used lo provide examples of software cost calcii- 
lations. 

The Need for Metrics 

As an example of the need for substantive software quali- 
ty cost data, consider the situation a project manager 
might encounter when attempting to justify the purchase 
and use of a new software development tool such as a 
sialic code analyzer. If the cost of the tool is $20,000 and 
if there is reliable data to suggest that the tool will un- 
cover 5% of the total number of software defects during 

Software Development Phases 



Requirements Analysis 
Design 
Code 
Unit Test 
Integration 

Metrics J System ana Acceptance Tests 
Database ) Release 

Postrelease 



Fig. l. Software Bfo cycle and the phases d"' software quality 
■-■iittineeriiiR metrics database covers. 



typical use, is the project manager justified in acquiring 
and using the tool? 

To provide answers to this type of question, it is impor- 
tant to have access to a reliable database of software 
quality metrics. Such a database is maintained by the 
software quality engineering group at the clinical systems 
business unit of HP's Waltham Division. This database has 
become an essential component of software quality activi- 
ties at HP Waltham and is invaluable for such tasks as 
project scheduling, resource planning, project and product 
quality status reporting, and software defect cost calcula- 
tions. 

In addition to maintaining the metrics database, the soft- 
ware quality engineering group works with H&D in testing 
and process improvement activities. 

Software Quality Metrics Database 

Fig. I indicates the development phases of a typical soft- 
ware project, wilh the phases indicated in which metrics 
are collected and stored into the soli ware quality data- 
base. Data is gathered from a variety of sources including 
software defect logging, product comparison studies, proj- 
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eel post-mortem studies, code complexity arid size analy- 
sis, and project schedule and resource plans. The physical 
data resides mainly in a standard UP STARS* database, 
which has been augmented with additional fields, files, 
and reporting utilities. All of the products represented in 
the metrics database are firm ware-based medical devices 
such as critical care monitors, arrhythmia analysis com- 
piling, anil c linical databases. 

Figs, 2, 3, and 4 represent various types of useful data 
that can be extracted from the database. Fig. 2 docu- 
ments the steps thai are typically required to find, fix, 
and retest a defect discovered by the software quality 
engineering group during integration and system or accep- 
tance testing. The engineering effort for this activity, 
which is shown as 20 hours, represents the average effort 
for finding and fixing one typical software defect. This 
value has been calculated using hundreds of dala points 
from multiple software projects that have been tracked 
wilh the software quality database. Fig. -i is an example 
of how an accurate schedule for the integration through 
the release phases can be developed using historical proj- 
ect data from the database. In Ihis case, it is clear that a 
stable and linear relationship exists between product code 
size and resultant calendar lime. Finally. Fig. I tabulates 
various software metrics from multiple software projects. 
This data can be very useful for developing project com- 
parison studies. 

The dala presented in these figures is a small subset of 
the data that exists in the database. This specific dala has 
been presented because of its applicability to software 
defect cost calculations. 

Looking for Soft ware Defect. Costs 

Software defect costs can be investigated using a variety 
of different approaches. For example, costs can be calcu- 
lated on a prerelease or a postrelease basis, or costs can 
be determined per defect or per project phase, or costs 
can be weighted based on code size or programmer pro- 
ductivity. The software defect cost data developed in this 
paper focuses on the cost per prerelease software defect 
that is found and fixed during the integration through the 



"The Software Tracking and Reporting System, or STARS, is an HP internal database 
lor tracking software delects. 
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Fig. 4. Typical Boil ware metrics lor projects in tin- software quality 
database. 

release phases of project development. This approach is 
used because of the abundance of reliable data points 
available for study and because of Ihe potential utility of 

the results. 

The Software Defect Cost Equat ion 

The calculation of prerelease software defect cost pro- 
posed here is based on the formula: 

Software Defect Cost = Software Defect Rework Cost 
+ Profit Loss 

Software defect rework cost is determined by ihe amount 
of effort and expense required to find and li\ software 
defects during the integral ion through release phases of a 
software project. Profit loss is the revenue loss that is 
caused by lower product sales throughout the entire post- 
release lifetime of the product. The lower sales factor is 
caused directly by the lengthy find and fix cycle of pre- 
release defects thai force a schedule slip and result in a 
loss of markfit-wlndOw opportunity. 

Many other factors could probably be used to determine 
the software defect cost but our data shows that Ihe re- 
work cost and profit loss factors have a major impact on 
the result and will supply a close firsl approximation of 
Ihe final value. Table I lists a set of product and project 
software factors that will be used to calculate a soflware 
defect cost value. All of these factors represent typical 
values derived from our database. 

Table I 

Typical Values in the Metrics Database 

Code size 78 KNCSS 

(i months 



Calendar time for pre- 
reli-asi- testing 

Number of prerelease 
defects found and fixed 

Prerelease defect density 



110 defects 
l.r.defects/KNCSS 



Software Defect Rework Calculation 

This calculation is very simple and is based on data pre- 
sented in Figs. 2 and 4 and Table 1. A typical product will 
have 110 software defects found and fixed during the 
project test phase. Each of these defects will require 20 
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engineering hours to find and fix- The total prerelease 
software rework effort then is: 

Software Defect Rework Effort = 110 x 20 = 2200 
engineering hours. 

To convert this effort value to dollars requires the S/hour 
software engineer factor. As a close approximation of an 
industry standard value, we will use $754iour as the stan- 
dard charge for the services of a software engineer. (This 
includes basic salary » administration overhead of 75%). 

Software Delect Rework Cost = 2200 hours x 
$75/hour = $165,000. 

On a per-defect basis, rework cost can be determined as: 

Rework Cost per Software Defect = 20 hours x 
S75/hour = 11600. 

These calculations are useful in highlighting the true 
waste factor of poor software quality. Each software de- 
fect is responsible for $1600 of unnecessary expense, and 
for a typical project $165,000 is required for software 
rework. 

Software Defect Profit Loss Calculation 

The other major factor contributing to software defect 
cost is product profit loss because of missed market-win- 
dow opportunities and the resultant loss of product sales. 
In other words, if a product release date slips because 
the software defect find and fix cycle is unnecessarily 
long, then potential product sales are irretrievably lost 
and overall lifetime profit dollars will be less. Such fac- 
tors as rapidly obsolete technology and the availability of 
competitive products also contribute to Ihe potential loss 
of sales. 

Several industry models '•- have been proposed thai < ;m 

be used to quantify ihe profii loss factor. Fig. 5 presents 

one of these models and will serve as the basis for our 
calculations. For Ihe following calculations we assume a 
1000-unit customer base of a $20,000 product with a 15% 
profit margin. This will yield $3,000,000 in lifetime pn.ru 
Assuming a six-month slip in product release because of 
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Fig. 6. Software defect tost summary for a typical software 
project. 

Ihe software defect find and fix cycle. Fig. 5 suggests a 
3396 loss in profit. 

Profit Loss = $3,000,000 X 33% = $1,000,000 

Using the data on the number of prerelease defects given 
in Table I, on a per-defect basis, profil-loss can be deter- 
mined as: 

$1,000,000/110 defects $9000 per defect. 

It may seem extreme to say that every prerelease defect 
causes a product to be lale lo market. However, because 
of the nature of our business, it is important thai our 
products perform reliably in the critical-care medical envi- 
ronment. This means that eac h defect of a high enough 
severity level thai is found during prerelease tests must 
he fixed and iciest ed before final release. Il is Ihis test, 
fix, and relcst cycle that delays product release and con- 
Iribules to the cost of poor software quality. 

The $1,000,000 Opportunity 

Fig. fi summarizes the software defect cost data calcu- 
lated in litis paper. The variables used in these calcula- 
lions will vary front One organization to another, but the 
fundamental algorithm for computing software defect cost 
is applicable to most cases. Although Ihe product cost 
and profit margin numbers used here are Tor illustrative 
purposes, they are typical for large software systems. 
Therefore, with ihe polenlial for a cost of $10,500 per 
defed and $1,185,000 per project, there is ample financial 
basis for a number of polenlial remedial actions. 

Quality Awareness. Most soli wan- engineers probably have 
HO idea about Ihe cost of reworking software lo find and 
fix a defect once the code enters the integration and test 
phases. They should be made aware of Ihe savings possi- 
ble if more defect detection could be done in Ihe early 

stages of product development 

CASE Investment. There are a large number of CASK tools 
and methodologies available lo augment the software dc- 
velopmenl process. Kxamples of modem CASK technolo- 
gy include sialic code analyzers, debuggers, execuliott 
profilers, formal inspections of design and code, struc- 
tured analysis and design, and so on. Mosl of these tech- 
nologies can be acquired for a financial investment of 
$1(1.(100 to $30,000. If each software defect has a $10,500 
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cost, then it is c learly appropriate to consider the use of 
CASE to improve software quality. 

Software 10X Program: When it becomes clear thai soft- 
ware quality improvements can yield Substantial financial 
rewards, then the goal of a 10 x gain in software quality 
assumes additional impetus. Consider that a 10 x im- 
provemcnl of the number of prerelease software defects 
for the typical software project presented in this paper 
would yield almost an additional $1,000,000 in profit. That 
figure is a powerful bottom line motivator. 

Conclusion 

This paper has presented a technique that can be used to 
calculate software defect cost values. Historical HP Wal- 



thani software quality and project data has been applied 
to cost calculations so lhal realistic results might be ob- 
tained. All hough additional investigations, such as a deter- 
mination of postrelease software defect cosl, might pro- 
vide a more detailed analysis of cost, (he data presented 
in this paper is accurate and provides compelling finan- 
cial motivation for improved software quality. 
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A Case Study of Code Inspections 

The code inspection process is a tool that can be used early in the 
software development cycle to help improve the quality of software 
products and the productivity of development engineers. 

by Frank W. Blakely and Mark E. Boles 



Code inspections have become an integral part of the 
software development life cycle in many organizations. 
Because it lakes some project time and because engineers 
initially feel intimidated by the process, code inspections 
have not always been readily accepted. Additionally, there 
has not always been enough evidence (metrics) to prove 
that for the lime and effort invested, the process has any 
value in reducing defects and improving overall software 
quality. Since the early clays, the process has become bet- 
ter understood and documented, and recent articles have 
provided concrete metrics and other evidence I o, justify 
the value of Ihe process. 1 -- 1 

This paper describes our experiences in bringing Ihe code 
inspection process to HP's Application Support Division 
(ASD). We describe both the positive and negative find- 
ings related to using code inspections. Although we only 
have metrics for one project, our main goal here is to 
present how we implemented Ihe inspection process and 
tO illustrate Ihe type of data to colled and whal might be 
done with the data. 

Background 

In li'SS our division was in the process of searching for 
best practices and methodologies that could help us meet 
or exceed the company-wide 10 x quality improvement 
goal. Design and code inspections were two of the meth- 
odologies lhal we proposed. Management agreed to sanc- 
tion a pilot projeel using code inspections, with imple- 



mentation of a design inspection process deferred to a 
later date-. 

The authors attended the software Inspections Class given 
by HP's Corporate Engineering software engineering train- 
ing group. This knowledge was then Imported to our divi- 
sion, and several c lasses were laugh! lo Ihe engineers to 
prepare them to be participants in Ihe code inspection 
process. 

To begin using the code inspection process on a pilot 
basis, a software project that involved enhancing an exist- 
ing product was selected. To ensure lhal we could im- 
prove Ihe process and learn from our experience, we de- 
cided to record and analyze the results from each code 
inspection. This way we would have some dala to back 
up any claims we had regarding the value of the process. 
The metrics and data we decided to collect and analyze 
included: 

• The criteria to use in selecting modules to inspect. 

• The criteria for selecting participants in the process. 

• The methodology used while performing the inspection. 

• The relative effectiveness of code inspections in improv- 
ing quality versus standard testing via module execution. 

• The merits of doing code inspections before or after 
bench testing a software module. 

• The number of defects found in a product in Ihe first year 
after release thai might have been found in code inspec- 
tions. 
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• The costs of addressing defects found in the first year 
after release during the inspection phase versus during 
the maintenance phase. 

Engineers from the quality and productivity department of 
our division taught the inspections class tiefore starting 
the pilot project. They also acted as moderators for the 
formal code inspections. R&D software engineers from 
several different projects participated as authors, readers, 
and inspectors. There was also a technical marketing en- 
gineer who participated as an inspector. 

Implementation of the Code Inspection Process 

Developing a set of criteria for which modules to inspect, 
who should participate in the inspections, and what meth- 
odology to follow were the first issues that needed to be 
resolved in implementing the inspection process. Two 
methodologies were used in our implementation: formal 
and informal inspections. The pilot project used the for- 
mal, more structured process presented in the inspections 
class, while later projects used both formal and informal 
methodologies. The comparative success of the two meth- 
odologies has not been fully determined, but some or the 
results are described later. 

Module Selection. Because a software product is made of 
many modules, the time it would lake to inspect every 
module might be prohibitive. Therefore, criteria must ex- 
ist lo determine which modules should be inspected. Two 
criteria were used lo identify the modules to be in- 
spected. First, modules were selected only if Ihey were 
modified in the course of the project (remember this was 
an enhancement project). Second, the complexity of (he 
modified modules was determined Module complexity 
has been shown lo be a good indicator of toe defect 

proneness of a software module — the higher the complex- 
ity, l he greater the likelihood there are defects. Therefore, 
Complexity was used lo identify those modules Dial Were 

the best candidates tor Inspection. The original plan was 

in determine the complexity of modules using the 
McCabe complexity loot. 1 which is based on the McCabe 

complexity metric." Unfortunately the McCabe tool could 
not accurately identify the complexity of the modules 
written in MS-DOS macro assembler language. This led to 

attempts to roughly quantify (he complexity of these mod- 
ules, relying OH the opinion of the moduli's author as to 

iis complexity. The result was that modules were in- 
spected based on Ihe amount of modification lo the mod- 
uli- and a rough estimate of their complexity, 

Participant Selection. A code inspection is a Structured 
process in which each participant has a clearly defined 
role. Inspection participants were selected based on their 
knowledge of Ihe language in which Ihe module was wril- 
ten. Attempts were also made lo select engineers who 
were also knowledgeable about Ihe high-level structure of 
the product We could not find many engineers with this 
knowledge so this criterion was abandoned and knowl- 
edge of Ihe development language became the predomi- 
nate criterion; 

Formal Code Inspections. The methodology we used for 
formal code inspections required thai the author select 



the module to be inspected and prepare inspection pack- 
els for the moderator, code reader, and inspectors." The 
code inspection packet was distributed two days before 
the scheduled inspection date. The packet consisted of a 
cover sheet and listings (with line numbers) of the mod- 
ule to be inspected. The cover sheet detailed the time 
and place of Ihe inspection meeting, the participants, and 
a brief description of the module to be inspected Be- 
cause some of the engineers who participated as inspec- 
tors and readers were unfamiliar with the design of the 
modules, additional information was sometimes added to 
ihe packets to improve the effectiveness of Ihe process- 
Additions included module descriptions, pseudo code, and 
design overview documents describing the design of the 
module. 

Before the meeting the moderator was responsible for 
confirming the availability of the meeting participants for 
the lime and dale of Ihe inspection. Inspectors were re- 
quired to prepare Tor Ihe inspection, and if they could not 
guarantee adequate preparation, notify the moderator so 
ihai the inspection could be rescheduled. Usually on the 
the day before the meeting. Ihe moderator would chec k 
in make sure thai everyone was ready. 

During the meeting Ihe following rules were followed to 
avoid conflicts and ensure a productive process. 

• Critiques of the coding style used in the module being 

Inspected were avoided. 

• Problems were to be indicated and identified, but solu- 
tions were not lo be offered during the inspection meet- 
ings. 

• Comments were to be phrased in a nonthrcatciiing way. 
Incusing on whal Ihe module did, as opposed CO what the 
author might have done-. 

• Antagonistic ways of expressing points of view were 
avoided. 

The meetings were limited lo one hour. Data from other 
divisions showed that longer meetings drained the inspec- 
tion team and decreased their effectiveness. 

Two forms were used lo gather Ihe data from Ihe code 
inspections: Ihe code inspection log and the code inspec- 
tion delail log (see Fig. 1). The code inspection log de 
scribed the module inspected, the participants, their prep- 
aration time. Ihe hours of engineering effort involved. Ihe 
number of lines inspected, and the number of problems 
identified. The defects identified were categorized by se- 
verity, and Whether and how they could have been found 
in the absence of code inspec tions. The code inspec tion 
detttil log identified a problem by page and line number 
in the module source, and provided a descriplion of Ihe 
problem and its severity. At Ihe end of the meeting a de- 
cision was made as to Ihe advisability of sc heduling a 
reinspection of Ihe module if the number of problems 
found was unacceptable. If the author made extensive 
changes to the inspected modules while fixing inspection- 
identified defects, this would possibly create a need for 
reinspeclion. 

"We actually had two inspectors The aulhoi acted as an inspector 
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Fig. 1. (al Code inspection loK. (Ii) ("ode inspection detail lug. 

In the post inspect ion meetings, lite moderator and the 
author met so thai the moderator could give the collected 
information to the author. The author was then responsi- 
ble for implementing the defect repairs, if enhancements 
had been identified in the inspection, tiiese were either 
accepted or rejected by Ihe author and the moderator. 

Informal Code Inspections. Informal code inspections were 
not a part of the pilot project. Several informal code in- 
spections were performed on later projects and as a pari 



Measure 


Data 


Pilot Project 


Lines ol NCSS Code Inspected 


1516 


Engineering Hours ot Preparation 


55-9 


Engineering Hours in Meetings 


30.4 


Number ol Delects Found 


21 


Number ol Enhancement Requests 


4 


Follow-On Pro|ects (Formal) 


Lines ol NCSS Code Inspected 


196 


Engineering Hours ol Preparation 


4.5 


Engineering Hours in Meetings 


4.0 


Number ol Delects Found 


1 


Number ol Enhancement Requests 


0 


Follow-On Projects (Intormall 


Lines ol NCSS Code Inspected 


1154 


Engineering Hours of Preparation 


0 


Engineering Hours in Meetings 


5.3 


Number ol Delects Found 


1 


Number ol Enhancement Requests 


0 



Fig. 2. Summary oroide inspection statistics. 



of the pilot project's GPE (current product engineering ) 
or postrelease activities. There was no preparation re- 
quired for these informal code inspections. The code's 
author would request that another engineer sit and look 
over a module or a suhmodule at the time of the meeting, 
There was no moderator, and no formal documental ion of 
the process. Usually, the engineer who was asked to in- 
spect was familiar with the overall design of Ihe module 
being inspected. 

Data Collected 

As mentioned earlier we Iried to collect data that would 
enable us to evaluate the effectiveness of the code in- 
spection process. The code inspection data collected in- 
cluded the number of: 

• Lines of noncoinmenl source statements (NCSS) in- 
spected 

• Engineering hours of preparation required 

• Engineering hours spent in code inspection meetings 

• Defects and enhancement requests found during the 
meeting. 

Because the effort required to fix a defect is the same 
regardless of how it is found, no data was collected on 
the time taken to fix defects or implement enhancements. 
Also, because Ihe implementation of the informal code 
inspection process was done in a way that permitted a 
wide variation in the statistics collected, insufficient data 
exists to determine clearly Ihe effectiveness of informal 
code inspections. Fig. 2 summarizes the statistics front 
our pilot project and some follow-on projects in which 
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Fig. 3. Major modules and pcn.-enl >>l cede inspei ted. 

both formal and informal rode inspection processes were 
used. Fig. 3 shows the major modules and the amount of 
code inspected from each module. 

From the data shown in Fig. 2, the ratio or preparation 
lime to inspection time can be calculated as 1.8.) for I he 
pilot project , and 1.13 for I he formal inspections done for 
a follow-on project. The ratio for all of the projects was 
1,78, The inspection rate for the pilot project was 2(X> 
lines oT NCSS per meeting hour." For the follow-on proj- 
ect it was 19tt lines, bringing the overall rale to 1!"!* lines 
per meeting hour. The defect finding rale was 0.2-13 de- 
fects per engineering hour (preparation hours plus meet- 
ing hours) for the pilot project and 0.118 for the follow- 
on project, bringing the overall defect finding rate to 
0.233. Work done by other IIP divisions showed that for a 
one-hour meeting. 200 lines of code is about the most 
that can be covered before the defect rinding rate begins 
lo decline. 

The metrics for preparation time and lines per meeting 
can be used to estimate for future projects the amount of 
time required for inspections so that projects can budget 
in their schedules a reasonable amount ol'limc for in- 
spections. The defect finding rale can be used to corre- 
late between the effectiveness of different types or testing 
and the complexity of modules so that the overall valida 
lion of the code design can be optimized. 

During the development phase or the project, test log 
sheets were used to collect dala about defects found dur- 
ing testing and the number ol' hours devoted to testing. 
This data was used to help analyze traditional testing 
WrSllS COde inspections. 

Detects reported by customers against the pilot product 
dining the firsl year after it-s release were also collected. 
The objectives ol" gathering this data were: 

• lb determine whether the delects were in modules that 
had been inspected 

• To determine why. If the delects were in inspected mod- 
ules, they were not found during the inspection 

• To determine why modules with delects were not in- 
spected 

"f ot each lorrnai inspection, there were 4 participants and a total ol 'JO 4 hours were 
spenl in meetings Thus, 30 4 engineering hours m meetings equals 1 6 meeting hours, 
resulting in TOO lines ptn meriting hour 1 1 51 6 lmes/7 5 meeting hours! 



• To determine the relative costs of addressing the defects 
found by customers compared with the cost of putting 
more effort into performing code inspections. 

The data collected also included the Dumber of hours of 
online and offline support spent identifying and verifying 
the problems, the number of engineering hours spent 
identifying the causes, the appropriate fix for the defect, 
and whether the modules in which tin- defects were 
found wen? inspected. Additional information allowed 
estimation of the time rc-quired to perform code inspec- 
tions on those modules not inspected. 

Comparison to Testing Process 

For comparison with the traditional testing process (i.e., 
module execution), derects for the pilot project were 
categorized according to the method used to find the de- 
fect and the defect cause. Fig. 4 shows this categorization 
for the pilot -project derects. Note the inclusion or custom- 
er-found derects. Fig. 5 shows the severity or derects 
found Classified by severity and lest type. Note that in- 
spections found defects in each or the standard severity 
categories. 

Figs. 4 and 5 do not reflect comment derects or detects 
resulting from incorrect design. Both types or detects 
wen' found and noted but not counted. 

II" Inspections Had not Been Done 

The detects round by code inspections were analyzed to 
determine whether they might have been found ir code 
inspections had not been done. While these classifications 
are not certain, they were our best determination based 
on knowledge of the product, the test environment, and 
the way in which the product would be used. Fig. (> 
shows where in the process we think certain delects 
would have been round if they had not been caught by 
code inspections. 

As a father aid in analyzing the effectiveness or code 
inspections as a verification tool, the delects round during 
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Fig. 5. Defects categorized by severity anil method of detection 

inspections were divided into categories based on the 

following questions about each defect. 

Would the defect have been found by the existing test 

process? 

Could a lest be devised to find those defects that would 
not be found by existing tests? 

Would customers find those defects that would not be 
found by existing tests? 

Would some of these defects not be found by any of the 
above methods? 

Of the 21 defects found by code inspections, only four 
could have been found with new tests. 

Defects Found by Customers 

An analysis was made of the defects found by customers 
in the time since the pilot product was released. This 
allowed us to attempt to determine why the defects were 
not identified and fixed before the release of the product. 
Fig. 7 shows the distribution of defects found by custom- 
ers and the reasons associated with the defects. These 
reasons include: 

The defect was a global error, not specific to a module or 
modules. 

The defect existed in a dependent product 
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• The module was not inspected because it was not modi- 
fied. This also indicated that our test suites were not thor- 
ough enough. 

• The module was not inspected because modifications 
were not considered significant. 

■ The module was inspected, but the defect was not identi- 
fied. 

The defects classified in the first two categories were 
those for which a code inspection could not have identi- 
fied I he defect. 

The cost of having customers find defects in the product 
compared to the cost of using code inspections to find 
these defects was measured by collecting cost informa- 
tion from the response center,- support engineering. RKI>. 
and test and manufacturing. The average lime of a re- 
sponse center call was determined and used to estimate 
the response center cost of handling a defect. The cost of 
the time spent by the support engineer was determined 
based on the lime spcnl in responding to calls about de- 
fects in the product. The cost of the time spent by devel- 
opment engineers was based on the lime spent identifying 
Ihe cause of the defect, the lime lo fix it if necessary, 
and the time required to lesl the defect once it was fixed. 
Estimates of the lime required to perform system testing 
and Ihe manufacturing costs were also collecled. The 
results showed that it costs approximately 100 limes 
more to fix a defeel in a released product than ii costs to 
fix a defect during the code inspection phase. 

One important cost that cannot be directly measured in 
currency is the loss of customer satisfaction when the 
customer finds a defect. Because this cost is hard lo 
quantify, it is sometimes ignored, but the fact is that il 
does affect the profitability of products. 

The response center is the primary contact for customers and HP field personnel to obtain 
help with HP software 
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not have been found if they had not been found during the codi 
Inspection process. 
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Benefits 

Besides the cost savings realized by finding and fixing 
defects before they reach the customer, there are other 
benefits associated with doing code inspections. These 
benefits are not easy to measure, but they do have an 
impact on quality and productivity. 

• Code inspections allow defects to I>e found early in the 
product development cycle. This has the iKMtefil of reduc- 
ing the number of product builds and certification cycles 
required to complete the dev elopment of a product. This 
Ix-nefit is difficult to quantify because there is no way to 
measure the build cycles that might be required for a giv- 
en number of defects. However, one product build and 
certification cycle is a minimum of 41) hours in our envi- 
ronment. 

• The code associated with a defect found during a code 
inspection is immediately identified at the inspection. 
When a defec t is found by testing, all that is known is that 
something somewhere doesn't work correctly, and the 
additional work necessary to identify the lines of code 
that are at fault is unknown. 

• Because code inspections require a great deal of commu- 
nication among the participants, cross training and idea 
sharing are byproducts of the inspection process. Other 
engineers involved become familiar with modules they 
did not write, and acquire a better understanding of the 
entire product. Also, engineers from other projects ac- 
quire a better understanding of products other than their 
own. 

Issues 

Four issues c ame out of the code inspection process. 
These were in the area of procedures or aspects of the 
implementation rather than condem n ati on s of the process 
in general. 

First, the primary consideration in selecting inspectors 
was their ability to read and comprehend tin- program- 
ming language being inspected. A lack of understanding 
of the design was not considered an impediment to par- 
ticipation. However, this was an impediment to making 
the Inspections as effective as possible because the in- 
spectors could not always effectively identify situations 
where the implementation did not match the intended 
design. 

This led lo the second area of difficulty -the need for 
formal design reviews. The lack of formal design reviews 
results in engineers outside of the project having little 
familiarity with the details, or even in some cases with 
the overall design or a product. A lack of a design review 
process inhibits the effec t iveness of code inspections on 
projects with a small number of engineers. 



The third issue involves deciding when a module should 
be inspected. We determined that the code inspection 
process should be used after the developer believes that 
the designed functionality is correctly implemented, and 
before testing is done. All inspectors and readers should 
be familiar with the overall product design and the imple- 
mentation of the module l>eing inspected. 

Finally, the defects that were missed and could have been 
found in the inspection process indicated that we need to 
find a way to improve the methods used to identify po- 
tential defect areas during the process. 

Conclusion 

Based on the data collected about the use of code iaspec- 
tions. anil the data concerning the cost of finding and 
repairing defects after the product has been released to 
the customer, it is clear that the implementation of code 
inspec tions as a regular part of the development cycle is 
beneficial compared lo the costs associated with fixing 
defects found by customers. 

The formal code inspection process is a significant bene- 
fit in fostering quality and productivity in product devel- 
opment. The formal process Ls structured and requires 
documentation and accountability. These attributes make 
it easy to measure and improve the process. From our 
experience with informal inspections, it is not clear 
whether the process provides any benefits. However, as 
an aid to improving the quality of the implemented code, 
it is worth further investigation. 
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10 Hardware Architecture 



Werner E. Heim 



6 Component Monitoring System 

Christoph Westerteicher 

Chris Westerteicher was ihe 
project manager for the HP 
Component Monitoring Sys- 
*S -S tern computer module and 

^ J» displays Asa result ot his 
' team's efforts, production of 
the HP Component Monitor- 
ing System has been auto- 
mated and streamlined to a 
major extent With parts standardization, only 300 
parts are needed for the entire system Chris joined 
HP's Bdblmgen Medical Division in 1980. shortly after 
earning a diploma in electrical engineering from the 
University of Stuttgart He became an R&D designer 
of displays and interface cards for HP medical moni- 
tors, and is currently a project manager for anesthe- 
sia information systems Chris is the author of a tech- 
nical article on IC design productivity and is a 
member of the VDE Born in Stuttgart, he lives in 
Leonberg. is married, has a daughter, and enjoys 
swimming, gardening, and traveling 




R&D engineer Werner Heim 
joined HP's Bdblmgen Medi- 
cal Division in 1986, soon 
after earning his electronics 
engineering diploma from 
the University of Braunsch- 
weig in Germany. He devel- 
oped computer module hard- 
ware, including the 
backplane, CPU, utility CPU, and EPROM, as well as 
the utility CPU firmware for the HP Component Moni- 
toring System Born in Giessen-Hessen. Germany, 
Werner lives In Herrenberg. Baden-Wurttemberg, and 
enioys music and books 

Christoph Westerteicher 

Author's biography appears elsewhere in this section 

13 Software Architecture 



Martin Reiche 

^^1^^ Project leader Martin Reiche 
w^^^^^ was responsible for the fun 

■ ^J^^ damental design of the soft- 
ra^^^l ware architecture, operating 

V system and development 
'^^^m environment, and patient 
J^^^P^ Sl 9 na ' processing software 

V^Vfi for the HP Component Moni- 
toring System His team's 
efforts resulted in automation of all external activities 
and a smooth integration of each module into the 
monitoring system Tins produced enhanced product 
reliability and efficiency After joining HP's Boblingen 
Medical Division in 1982, he developed ECG and re- 
spiratory signal processing for the HP 78832 and 
78833 neonatal patient monitors Martin received his 
electrical engineering diploma in 1981 from the Uni- 
versity of Wuppertal Born in Wuppertal near Co- 
logne. Germany, he lives in Gaufelden, is married, and 
has one child He enioys bicycling, music, and natural 
and life sciences, especially psychology 

19 Parameter Module Interface 



Winfried Kaiser 

Winfried Kaiser was the 
project leader and designer 
f^^^^^ lor the parameter module 

I ■ interface, front-end firrn- 

/ ware, module rack, and 

~"-^Fm some of the parameter mod- 
T^^F** ules for the HP Component 

VjBPJ Monitoring System His ef- 

forts resulted in a front-end 
link that provides fast response, optimum use of 
available bandwidth, configuration detection, and 
synchronization for a wide variety of modules After 
earning his engineering diploma in 1982 from the 
University ot Karlsruhe. Winfried joined HP's Boblin- 
gen Medical Division in 1982 He has developed hard- 
ware and firmware and been a project leadet for sev- 




eral patient monitoring systems, and is now a project 
manager for patient monitoring products and en- 
hancements Born In Lahr in the Black Forest. Win- 
fried lives m Bdblmgen, is married, has one son. and 
enioys traveling, swimming, and family activities 

21 Measuring the ECG Signal 



Wolfgang Grossbach 

Hardware R&D engineer 
Wolfgang Grossbach de- 
signed and developed the 
ECG/respiration HP Ml 001 A 
and M1002A modules and 
mixed analog-digital applica- 
tion-specific integrated cir- 
cuits (ASICI for the HP Com 
ponent Monitoring System 
The modules and circuits produced significant reduc 
lions in cost, power consumption, size, and compo- 
nent count Wolfgang joined HP's Boblingen Medical 
Division m 1985. shortly after receiving his electronic 
engineering diploma from the University of Stuttgart 
Born in Salzburg, Austria, Wolfgang lives m Murr, 
Germany. He is married, has two daughters, and en- 
joys jogging, bicycling, photography, and reading. 

25 Blood Pressure Module 



Rainer Rometsch 

Mechanical design engineer 
Rainer Rometsch developed 
the pump assembly for the 
noninvasive blood pressure 
module and plastic parts for 
the display front assembly In 
the HP Component Monitor- 
ing System The result of his 
1 efforts is one of the smallest 
self-contained noninvasive blood pressure modules in 
the world — a unit that can be built m about two min- 
utes Rainer joined the R&D unii at HP's Medical 
Products Group Europe in 1986. and is now working 
on respiratory gas measurement He is named as an 
inventor m a patent on noninvasive blood pressure 
measurement He received an engineering diploma in 
1986 from the Engineering Schoul of Furtwangen 
Born in Miihlheim/Donau (Baden-Wurttemberg), Rain- 
er lives in Wildberg in the Black Forest He is married, 
has two children, and enjoys working on his house 
and garden and restoring old BMW motorcycles 

26 Stripchart Recorder 



Leslie Bank 

Project manager Les Bank 
helped develop the two- 
channel stripchart recorder 
for the HP Component Moni- 
toring System The efforts of 
his team resulted in a break- 
through m reducing the size, 
cost, and power consump- 
tion of monitoring recorders. 
Les, a member of the IEEE, earned a BS degree in 
electrical engineering in 1969 from the City College of 
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New Vert and an MS Degree in eiectrical engineering 
m 1973 from Northeastern University He joined HP's 
Waltham Drvision in 1973 as a production engineer, 
working on patient monitoring systems Before join- 
ing HP. Les was a design engineer with Raytheon Co 
Born m New York City, he lives in Framingham. Mas- 
sachusetts, is mamed, and has two children 



29 Human Interface 



Gerhard Tivig 

Gerhard Tivig was the proj- 
ect leader for development 
of the human interface for 
the HP Component Monitor- 
ing System He also devel- 
oped software for the alarm 
manager and localization 
tools that allow efficient 
generation of local language 
versions so the monitor can be used worldwide Ger- 
hard joined HP's Boblingen Medical Division in 1980. 
where he researched and developed display software 
and invasive pressure parameters for HP monitoring 
systems He received an engineering diploma in 1 975 
from the Technical University in Bucharest. Romania, 
and later worked for two years as a system program- 
mer for bedside monitor software systems at Mennen 
Medical Center in Israel He is named an inventor in a 
European patent for the Component Monitoring Sys- 
tem's human interface Born in Bucharest, Gerhard 
lives in Bdblingen He is married, has two daughters, 
and enjoys family activities and traveling 



Wilhclm Meier 

Wilhelm Meier was the de- 
sign engineer responsible (or 
the HP Component Monitor- 
ing System's human inter- 
face design, simulation, and 
implementation He de- 
signed an intuitive, easy-to- 
use consistent control sys- 
tem for all applications and 
all members ol the HP Component Monitoring System 
family He |oined HP's Boblingen Medical Division in 
1982 and developed human interface software tor the 
HP 78353, 78834. and 78352 medical monitors, gain- 
ing experience in human factors and human interface 
design He is named an inventor in a European patent 
for the Component Monitoring System human inter- 
face He is now responsible for improvements and 
enhancements to the Component Monitoring System 
human interface software Wilhclm earned an electri- 
cal engineering diploma from the Technical University 
nf Hannover in 1981 Born in Obernkirchen in Lower 
Saxony, he lives in Herrenberg, Baden-Wurtternberg. 
is married, and has two children 



37 Globalization 

Gerhard Tivig 

Author's biography appears elsewhere in this section 




40 Physiological Calculation 



Steven J. Weisner 

As "-he software project lead- 

J the HP Component Monrtor- 
tng System beds ■ 

^^^^H Sieve Weisner was respon 
*v sible for the system's exter- 

^ ^^ph 'd £ on- 

^■J^^^l ^^^M tnbuted to software 
i^i^l^i^^i^i™ Jeveiopment His team's 
efforts resulted in a physiological calculation applica- 
tion that reduces the large amount of raw vital-signs 
data into derived values the clinician uses to assess a 
patients condition He joined HPs Waltham Division 
in 1982 and has worked as a project leader for the HP 
central station and as a software engineer for the HP 
arrhythmia monitoring system. SDN interface, and 
patient data management systems His professional 
specialties include human interface design and clini- 
cal information management Steve is now a soft- 
ware project leader for HP cardiac care systems, re- 
sponsible for external specifications and user 
interface design Before joining HP. he was a soft- 
ware engineer with Cornell University He received a 
BA degree in 1976 in biology from Cornell University, 
and an MS degree in 1981 in biomedical engineering 
from the University of Wisconsin A member of the 
IEEE, he is the author of technical articles in the IEEE 
Transactions on Biomedical Engineering and in the 
Proceedings of the Human Factors Society Bom in 
Paterson, New Jersey, he lives in Lexington. Massa- 
chusetts, has a daughter, and enjoys bicycling and 
sailing 



Paul Johnson 

Paul Johnson, a software 
development engineer 
whose professional interests 
include real-time operating 
systems, implemented the 
hemodynamic, oxygenation, 
and ventilation physiologic 
calculation displays and for- 
mulas for calculating the 
displayed values for the HP Component Monitoring 
System These calculated values are good predictors 
of ma|or malfunctions or mortality in intensive care 
patients. Paul |Oined HP's Waltham Division in 197H 
after receiving a BSE degree in 1968 from Purdue 
University and an MSCP degree in 1986 from the Uni- 
versity of Lowell m Massachusetts He was a soft- 
ware engineer for HP's computer-aided manufacturing 
department, a production engineering manager, and a 
development engineer in R&D Before joining HP, he 
was a development engineer with the Medical Divi- 
sion of American Optical Co. and a hardware engi- 
neer with Raytheon Corp A six-year U S Navy veter- 
an, Paul was horn in Elkhart. Indiana, and lives in 
Groton, Massachusetts He is married, has two chil- 
dren, and enjoys playing golf and listening to \au 





44 Mechanical Implementation 



Karl Daumuller 

Karl Daumuller was the me- 
chanical design project lead- 
er for the computer module, 
displays, and mounting hard- 
ware for the HP Component 
Monitoring System He 
helped reduce the number of 
pans dramatically over pre- 
vious patient monitonng 
designs. After joining HPs Boblingen Calculator Divi- 
sion in 1979, he served for two years as a process 
and production engineer for desktop computers and 
peripheral products Karl worked as a mechanical 
design engineer for over eight years ai HP's Boblin- 
gen Medical Division, developing the HP 7835x family 
of patient monitors. HP 8040 and 8041 cardiotoco- 
graphs, and mounting hardware for hospital installa 
tions. Now the virtual source engineering manager 
for the Boblingen Manufacturing Operation, he is re- 
sponsible for centralized sourcing of sheet metal and 
cabinet parts for all German manufacturing divisions 
Karl received an engineering diploma from the Engi- 
neering School of Esslmgen in 1979 Bom in Stuttgart 
in Baden-WUrttemberg, he lives in Filderstadt, is mar- 
ried, has four children, and enjoys family and church 
activities and gardening 

Erwin Flachslander 

Mechanical engineer Erwin 
Flachslander was responsi- 
ble for the mechanical de- 
sign of parameter modules 
for the HP Component Moni- 
toring System He helped 
design an enclosure that can 
be assembled and serviced 
without any tool Erwin 
joined the R&D division of HP's Boolingen Medical 
Division in 1985. shortly aftei receiving his mechani- 
cal engineering diploma from the Engineering School 
of Ulm At HP, he has worked on a TC-p0 2 /C0? cali- 
brator system He is named as an inventor in a patent 
do a connector for the blood pressure monitor Before 
joining HP. Erwin was a mechanic in manufacturing 
and production at two different companies Born in 
Kempten, Bavaria, he lives in Boblingen, is married, 
has two children, and enjoys motorbiking. photogra- 
phy, and playing a music synthesizer 

49 Automated Test Enviornment 



Dieter Goring 

^^p^ Software quality engineering 
f^^^^^L manager Dieter Goring de- 
I velnped the automateil soft- 

W?5 P'^B ware test environment for 
-J* the HP Component Monitor- 

^^HpY my System He designed the 
J AUT0TEST tool and devel- 
^▼r oped a suite of structured 
' tests, which runs 60 hours of 

automatic tests and 45 hours of semiautomatic tests 
overnight and weekends Dieter received his engi- 
neering diploma from the Engineering School ol Fun- 
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wangen in 1967. After joining HP's Computet Systems 
Division m Boblingen, Germany in 1973, he served as 
an R&D engineer, project engineer for automated test 
systBms, communications and office automation man- 
ager, and information technology manager Before 
loinmg HP. he was an application programmer and a 
software project engineer. Born In DiisseldDrf, he 
lives in Boblingen. is married, has two children, and 
enjoys sports, music, reading, and traveling. 

52 Production and Final Test 



Otto Schuster 

^^■1^ Production engineer Otto 

Schuster was responsible for 
■ ■ the production process de- 

™ -» velopment and design for 

i f manufacturing o! the HP 

Component Monitoring Sys- 
tem. He helped ensure the 
concurrent design of the 
product and its produclion 
processes— the first HP product designed in surface- 
mount technology in the Bdhhngen technology center. 
Otto joined HP's Boblingen Medical Division in 1979, 
shortly after receiving an engineering diploma in elec- 
trical engineering from the Engineering School of 
Esslingen He served as a production engineer tor the 
HP 78352, 78353, and 78354 monitoring systems A 
resident of Heimsheim in Baden-Wurttemberg, where 
he was bom. Olto is married, has two sons, and en- 
joys skiing, bicycling, and gardening. 

Joachim Welier 

Production engineer Joachim 
Waller was responsible for 
the design and development 
of front-end production test 
systems for the HP Compo- 
nent Monitoring System and 
for HP-UX tools for statistical 
process control He also 
worked closely with R&D on 
design testability, and helped reduce manufacturing 
cycle time on the monitoring system After joining 
HP's Boblingen Medical Division in 1984. he was re- 
sponsible to the production of patient monitors and 
the development of a new generation of final test 
systems for the HP 78352. 78354, and 78356 patient 
monitoring systems. Joachim received an engineering 
diploma in 1984 from the Engineering School m Ess- 
lingen. Born in Stuttgart in Baden-Wurttemberg, he 
lives in Herrenberg. is married, has two children, and 
enjoys amateur radio, windsurfing, camping, and 
studying foreign languages 

55 Cost of Software Defects 




William T Ward 




Jack Waro joined HP's Wal- 
tham Division in 1982 and 
has worked on the software 
and firmware development 
of critical care bedside moni- 
tors, arrhythmia analysis 
systems, and medical data- 
base systems. As the man- 
ager of software quality en- 




gineering, Jack is now responsible for testing each of 
these products for use in medical environments. He 
earned a BS degree in linguistics in 1972 from the 
University of Illinois and an MS degree in computer 
science in 1984 from Boston University. Before joining 
HP. he worked as a software support engineer for 
Data General Corp The author of several articles pub- 
lished in technical journals. Jack teaches undergradu- 
ate and graduate courses in C, C++, and software 
quality al Boston University Born in Winona. Missis- 
sippi, he lives in Btookline. Massachusetts, is mar- 
ried, has three children, and enjoys music, gardening, 
and logging 

58 Code Inspections 



Frank W. Blakely 

Client/server computing and 
software quality improve- 
ment are the professional 
interests of Frank Blakely. a 
software engineer at HP's 
Applications Support Divi- 
sion Frank |oined HP's In- 
formation Resources Opera- 
tion in 1980 He helped 
develop a code inspection process tool for HP's Data 
Management Systems Division that is now used early 
m the software development cycle to help improve 
ihe quality of software products and the productivity 
of development engineers at his division. Before lam- 
ing HP. Frank was an MIS programmer at LooArt 
Press, Inc and a programmer/analyst with Informa- 
tion Resources Ltd. He is a graduate of Colorado Col- 
lege, earning a BA degree in mathemaiics in 1973, 
and a graduate of the University of Oregon with an 
MS degree in mathematics in 1977. Frank is named 
as an inventor in a patent pending on HP cooperative 
services Born in Colorado Springs, Colorado, Frank 
lives in Roseville, California, is married, and enjoys 
cross-country skiing, hiking, playing board games, and 
participating in the Placer County Fair Association, 

Mark E. Boles 

MMk ^^^^ A software quality engineer 
wPjAP^I Nl HP's Applications Support 
Division, Mark Boles is re- 
sponsible for metrics collec- 
tion, process improvement, 
and implementing processes 
and new methodologies for 
software development He 
helped develop a code in- 
spection process model for HP's Data Management 
Systems Division that is now used early in the soft- 
ware development cycle to help improve the quality 
of software products and the productivity of develop- 
ment engineers at his division. Mark joined HP's Com- 
puter Systems Division in 1982, shortly after earning 
a BSEE degree from San Jose State University. He 
became a hardware reliability engineer for environ- 
mental and reliability testing for the HP 3000 comput- 
er and process improvements, and later a software 
quality engineer responsible for test and productivity 
tools Client-server application integration is his pro- 
fessional interest. Mark is a member of the American 
Society of Quality Control Born in National City, 
California, he lives in Roseville, is married, and en|oys 
car restoration, snow and water skiing, and building 
electric trams with ins three-year-old son. 





69 HP Vectra 486 PC 



Larry Shintaku 

Project manager Larry Shin- 
taku and his team developed 
the HP Vectra 486 PC acces- 
sories. Their new develop- 
M i ment processes helped HP 
I market the first personal 
)MM> computer to use the Intel486 
'^T^ microprocessor with an EISA 
bus Larry |oined HP's Data 
Terminals Division in February. 1980, two months af- 
ter receiving a BS degree in electrical engineering 
from Fresno State College In California. As a hard- 
ware designer, he developed Ihe HP 2623A/2 termi- 
nal graphics subsystem, and later, as a project man- 
ager, he helped develop the expanded memory card 
for the HP 1 50 Touchscreen PC. Larry is now manag- 
ing the development of the next generation of HP 
Vectra 486 PC products Before joining HP, he worked 
in digital communications with Daniel Inc. A member 
of the IEEE. Larry was born in Fresno and lives in 
Union City He enjoys racquetball. low-budget motion 
pictures, and Softball 
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Michael B. Raynham 

Exploring the creative links 
between art and technology 
are among the professional 
™ ' i , , • ! Mike Raynham, 

' r v . n an R&D development engi- 
^^^^^^ hee< 3< HP's California Per- 
sonal Computer Division 
Mike helped design the HP 
Vectra 486 PC and its Ex- 
tended Industry Standard Architecture (EISA) connec- 
tor He helped achieve an extremely fast development 
cycle of six months from initial concept to production 
of the first EISA connectors, which allow EISA amd 
ISA I/O cards to be handled in the same connector 
Mike also worked on hardware development for the 
HP 21 16B. 2100A, and 3000 computers, the HP 
2644A. 2645A. 2648A, 2547A, and 2703A terminals, 
and Ihe HP 1 50 TouchScreen II, HP Vectra RS16/20, 
and HP Vectra 486 personal computers Before joining 
HP in 1963 in Bedford. England, he worked as a film 
recording engineer with the British Broadcasting Cor- 
poration and as an apprentice with British Aerospace 
He is named as an inventor in patents or patents 
pending for a display panel, digital encoding/decod- 
ing techniques, DRAM on-chip error correction, low- 
cost connectors, and IC surface-mount process defect 
detection designs Mike is a member of the IEEE and 
acted as chair of the Desktop Futurebus+ subcommit- 
tee He earned an H N C degree in 1962 from Luton 
College of Technology and an MS degree in 1 971 
from Santa Clara University, both in electrical engi 
neenng. Born in Wmnersh, England, he lives in the 
Santa Cruz mountains in California, is married, and 
has two sons He enjoys clay sculpture, ceramic tile 
painting, and watercolor painting 
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Douglas M. Thorn 



As an engineer and project 
manager. Doug Thorn per- 
formed research and devel- 
opment on HP's fiber optic 
components He is now a 
sect-on manaoer ai HP's 




achieve an extremely fast 
development cycle of six months from initial concept 
to production of Ihe first EISA connectors, which al- 
low EISA and ISA I/O cards to be handled in the same 
connector He |oined HP's Optoelectronics Division in 
1980. and is now listed as an inventor on a patent on 
fiber optic component design and an inventor on a 
patent pending on the EISA connector Before joining 
HP. he was a consumer product designer with Nation- 
al Semiconductor Corp and Fairchild Semiconductor 
He earned BS degrees m 1975 m electrical and me- 
chanical engineering from the University of California 
ai Davis. Born in San Mateo. California, Doug lives in 
Woodside. California, is married, and has a son He 
enjoys sailing, carpentry, architecture, cooking, and 
gardening 

78 HP Vectra Memory Controller 



Marilyn J. Lang 

Marilyn Lang joined HP's 
California Personal Comput- 
er Division in 1981 and 
worked on IC test vector 
generation and simulation 
for the HP 150 video control- 
ler ASIC She also designed 
the HP-HIL port extender 
used in the HP Vectra RS/16, 
RS/20 and ES/12 PCs Marilyn then worked on 
memory subsystem analysis and design for the HP 
Vectra 386 PC, which led to her work 0(1 the memory 
controller ASIC design for the HP Vectra 486 PC. Her 
efforts helped produce a high performance, burst- 
mode capability that enhanced the competitive price/ 
performance ul the HP Vectra 486 PC Marilyn earned 
a BS degree in 1975 in chemistry Irom the Southern 
Illinois University at Carbonriale, an MS degree m 
uiochernistry in 1979 from the University nf Illinois at 
Urbana, where she also studied computer science, 
and an MSCSE degree ifl 1988 in computer science 
and engineering from Sanla Clara University Born in 
Chicago, Illinois, Marilyn lives in Milpitas, California, 
is mariied, has a daughter, and enjoys gardening, 
science fiction/fantasy, and classical music She is a 
member of the National Gardening Association and 
various humane and wildlife societies 

Gary W Lum 

Project manager Gary Lum, 
whose professional special- 
ties include memory technol- 
ogy and design, was respon- 
sible for developing the HP 
Vectra 486 memory control 
ler and memory subsystem 
architecture His eflorts re- 
sulted in a high-performance 
burst -mode memory capability that helped enhance 
the competitive jirice/performance advantage of HP's 





25-MHz system Gary |omed HP's Data Terminals Divi- 
sion in 1979 and workea as a project manager tor HP 
Vectra PC accessory cards, on the HP Vectra PC and 
HP Vectra ES PC, and on IC des.gn tor the HP 150 
TouchScreen II PC A member of the IEEE, Gary was 
bom m Syracuse. New York. Irves m Cupertino. 
California, rs married, and enjoys film and film history. 
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Thomas Tom 

R&D software engineer 
Thomas Tom |omed HP's 
California Personal Comput- 
er Division m 1989 and de- 
veloped the firmware for 
security features and the 
Micro-DIN mouse support for 
the HP Vectra 486 Basic I/O 
system IBIOS) He is now 
designing sutiware to support features of HP's new- 
est PCs Thomas is a 1983 graduate of the California 
Polytechnic State University at San Luis Obispo with 
a degree in electrical engineering Before joining HP, 
he developed real-time satellite simulation software 
for Stanford Telecommunications, Inc., and developed 
test software to evaluate integrated circuits at NEC 
Corp Thomas lives in San Francisco, where he was 
born, and enjoys basketball, tennis, bowling, and bik- 
ing 



Irvin R.Jones, Jr. 

Computer and system archi- 
tecture and artificial intelli- 
gence are the professional 
interests of Irvin Jones, a 
software engineer who 
helped develop the HP Vec- 
tra 486/25T system BIOS 
His efforts helped ensure 
that the HP Vectra 486 PC 
makes Ihe most efficient use of its Intel486 micropro- 
cessor, the EISA bus, and new memory subsystem 
Since joining HP's California Personal Computer Divi- 
sion in 1988, Irvin also helped design the system 
BIOS and system utilities disk for the HP Vectra 
LS/12, the HP Vectra 486/33T PC. and the HP Vectra 
386 PC Before |oinmg HP, Irvin worked as a digital 
designer on photocopier function cards for IBM, on 
the microcontroller design of professional video sys- 
tems for Sony Corporation, and on a parallel comput- 
er peripheral interlace for Bell Communications Re- 
search. A member of the IEEE and the Triathlon 
Federation, Irvin is named as an inventor of two pat- 
ents pending for HP's PC BIOS He earned a BS de- 
gree in electrical engineering from Stanford Universi- 
ty in 1982. an MS degree in computer engineering in 
1986 and an MS degiee in computer science in 1988 
from the University nf California at Santa Barbara 
Born in Dayton. Ohio, he lives in San Jose, California, 
and enjoys triathlon competition, playing jaw on the 
vibraphone and drums, and collecting comic books 



Christophe Grosthor 





ftl 



Real-time low-level software 
design and application de- 
velopment am the profes- 
sional specialities of Chris- 
tophe Grosthor He joked 
HP's Grabble Personal Cosn- 




Vectra 486 PC BIOS and the HP Vectra 386/25T PC 
BIOS He helped ensure that the HP Vectra 488 PC 
makes the best use of its Intel486 microprocessor, the 
EISA bus. and a new memory subsystem He received 
an MS degree in electronics from the University of 
Toulouse. France, ifl 1986 and a software engineering 
degree from Ecole Nationale Supeneure des Telecom- 
munications de Bretagne m 1988 Before joining HP 
Christophe worked on obiect-oriented compile* de- 
sign as a software engineer for Interactive Software 
Engineering. Inc in Santa Barbara. California Born m 
Strasbourg, France, he lives in Grenoble, is married, 
and enjoys sports, mountain hiking, and traveling. 



Viswanathan S. Narayanan 

^^^^p^^J Software development engi 
"^^M^^^bT =er Sun Narayanan devel- 

W ■ : ed the EISA initialization 
HfBJT ^ W procedures for the HP Vectra 
486 PC BIOS His efforts 
, helped ensure that the HP 
1 1 Vectra 486 PC makes the 
best use of its Intel486 mi- 
croprocessor, the EISA bus. 
and a new memory subsystem After joining HP's 
California Personal Computer Group in 1988, he de- 
veloped BIOS designs for the HP Vectra 386/25 PC. 
and is now working on future HP personal computer 
products Sun received a BS degiee in 1980 from Ihe 
Regional Engineering College in Warangal. India, and 
an MS degree in electrical engineering in 1985 Irom 
the University of Wyoming Born in Secunrierabad. 
India, he lives in Fremont, California, is married, and 
enjoys gardening and playing basketball 



Philip Garcia 

■ L Pini Garcia was responsible 

■ I tin ihe EISA CMOS BIOS 
interlace and the cache con- 
trol BIOS code He has 
worked nn keyboard micro- 
controller fumware design 
and PC utilities design for HP 

Vectra PCs After joining HP's 
- — ^ Data Terminals Division in 
1982 as a development engineer, fie worked on ana- 
log design for the HP 2700 color graphics workstation 
and the HP 150 Touchscreen PC, and on EMI/RFI com- 
pliance design tor the HP 150 and HP Vectra PC. A 
Stanford University graduate, he received a BAS de- 
gree m economics and electrical engineering in 1979, 
and an MSEE degree In analog IC design in 1981 Phil 
is named as an inventor in two pending patents on PC 
BIOS designs. Born in New York City, he lives in Sara- 
toga. California, is married, and enjoys hiking, skiing, 
old movies, and museums 
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92 Vectra Performance Analysis 



John D. Graf 

^^^^fc Development engineer John 

Graf joined HP's California 
f^^^^l Personal Computer Division 

™ * ■' in 1989. right after earning a 
y . V * BS degree in electrical engi- 
^^^B , neering from Rice University 

-rf y He then designed hardware 
tools to measure the perfor- 
'" **** mance of existing PCs. and 

developed mathematical and software models to 
evaluate and predict the performance of future archi- 
tectures These performance tools were used to de- 
sign and enhance the performance of the HP Vectra 
486 PC and the HP Vectra 486/33T PC. John's profes- 
sional interests are focused on evaluating the perfor- 
mance characteristics of CPU. cache, memory, and 
video Born in Baton Rouge, Louisiana, he lives in 
Sunnyvale. California, is married, and enjoys Cajun 
cooking, bodysurfing. and volunteer work in a church 
youth group 



David W. Blevins 

As a hardware development 
engineer at HP's California 
^^^^BM Personal Computer Division, 
— Dave Blevms developed the 

• A hardware for the backplane 
• I/O monitor, a noninvasive 

1 ' i lno ' ,haI he ' ps analy2e a 

1 \ 1 1 Iw/ll 1 1 1 Dersona ' computer's subsys- 
■ 1 1 IK 1 1 lem WOI ki oa( j a „rt provides 

data for predictive system modeling Dave, who 
lOined HP's Southern Sales Region m 1982 as a cus- 
tomer engineer in the New Orleans sales office, was 
a member of the HP Vectra RS/20 development team, 
a CAE tools support engineer, and a hardware devel- 
opment engineer He left HP in 1990 to jam MINC, 
Inc. in Colorado Springs, Colorado, as an applications 
engineer Dave received a BSEE degree in 1982 from 
Washington State University Born in Middletown, 
Ohio, he lives in Colorado Springs, Colorado, and is 
married Dave enjoys music synthesizers and comput- 
er music sequencing, high-performance motorcycles, 
mountain biking, and playing guitar in a local jazz-fu- 
sion group 




Christopher A. Bartholomew 

Chris Bartholomew |0ined 
HP's California Personal 
Computer Division in 1989 
soon after earning BS de- 
grees in computer science 
and in electrical engineering 
from Texas A&M University 
As an HP system perfor- 
mance engineer. Chris devel- 
oped the disk. I/O. and BIOS performance modeling 
hardware and software tools that help to noninva- 
sive^ analyze a personal computer's workload in 
these subsystems These tools were first used to de- 
sign and enhance the performance of the HP Vectra 
486/25T PC and the HP Vectra 48B/33T PC Chris' 
professional interests include embedded program- 
ming, ob|ect-oriented programming, performance 
modeling, and multiprocessor architectures He is a 
member of the IEEE and the IEEE Computer Society 
Before |oming HP. he was a systems programmer at 
Compaq Computer Corp Born in Jackson. Michigan. 
Chris lives in Fremont. California, is married, and en- 
joys camping, radio-controlled airplanes, fishing, and 
racquetball 
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The HP Vectra 486 Personal Computer 



The HP Vectra 486 series of computers uses the Intel486™ microprocessor, 
a custom-designed burst-mode memory controller, and the HP 
implementation of the Extended Industry Standard Architecture (EISA). 

by Larry Shintaku 



The IIP Vectra 486 PC was the first of Ill's new genera- 
tion of personal computers using the Intel486 micropro- 
cessor and the EISA (Extended Industry Standard Archi- 
tecture.) bus architecture. The Intel486 is a high-perfor- 
mance microprocessor thai integrates the GPU, 8K bytes 
of c ache, and a math coprocessor onto one chip running 
at a clock speed of 25 or 33 MHz* The CPL" instruction 
set is optimized to execute instructions and move data in 
fewer clock cycles than its predecessor, the Intel386 mi- 
croprocessor. The EISA bus was defined by an industry 
consortium of which HP is an active member. The EISA 
bus definition objectives were to nugrate the existing 
16-bil Industry Standard Architecture (ISA) bus into a 
32-bit bus, improve the DMA performance, and provide 
support for multiple bus masters while maintaining back- 
wards compatibility with all existing ISA backplane I/O 
cards. 

The HP Vectra 486 development objective was to deliver 
these two new technologies to market quickly We were 
presented with several technical and product development 

• Recent releases ol the HP Vectta 4B6 series include the Vectra 486/25T and Vectra/33T, 
the lattei uses the 33-MH* versiun of the Intel486 miciopiocessor 



challenges in trying to meet this objective. These chal- 
lenges included: 

• Defining a physical bus connector that would accommo- 
date both EISA and ISA cards (see article on page 73 1 

• Incorporating all the new technical design features that 
EISA offers 

• Developing performance enhancements targeted for the 
memory and mass storage subsystems. 

System Overview 

The Vectra 486 uses the existing upright floor package 
that is used by the HP Vectra RS series (see Fig 1). Its 
mass storage, power, anil feature options matched our 
customer requirements for high-end server and CAD appli- 
cations. The form factors for the printed circuit boards, 
already defined by the Vectra RS PC package, fixed the 
amount of logic each board could support, the logic de- 
sign and printed circuit board partitioning, and the func- 
tional, EMC, and performance objectives. The functional 
objectives were met by partitioning the system compo- 
nents so that follow-on EISA products could easily lever- 
age core components developed by the HP Vectra 486 




Fi«. 1. The HI' VV< ti;i ISt". |»'t 

sonal computer, 
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team. The BMC objectives were met by minimizing, 
through design, source radiation and harmonics caused by 
mismatched impedances. The design required that clock 
speeds up to Cifi MHz be distributed over several printed 
circuit boards and connectors. Meeting the EMC objec- 
tives was very Important since they represented a poten- 



tial delay in the schedule if regulatory requirements were 
not met. The performance objectives were met through 
the development of an Intel486 burst-mode memory con- 
troller and a high-performance hard disk subsystem. The 
hursl-niode memory controller is described on page 78 
and I he disk subsystem is discussed on this page. 



The HP Vectra 486 EISA SCSI Subsystem 



HP's advanced PC mass storage products have consistently provided customer; 
with performance and conformance to industry standards Ihe HP Vectra 486 PCs 
continue this tradition by providing a high-performance storage subsystem that is 
compatible with EISA and SCSI-2 (Small Computer System Interface) industry 
standards. 

The investigation Df customer needs for the first EISA PC, Ihe Veclra 486, revealed 
that the highest-performance PCs were entering new application areas. Customer 
and application requirements resembled more ihose of ihe workstation or mini- 
computer user than ihose of an individual running a word processing application 
Demanding compatibility with ihe IBM PC AT, cusiomers also insisted upon high 
capacity, performance, and reliability for such applications as PC CAD, multiuser 
UNIX" operating systems, and multiclient file servers 

HP's California PC Division's (CPCD) advanced storage team responded by develop- 
ing, along with its invaluable partners at HP's Disk Memory Division (DMDI and 
Adaptec, a new ESDI (Enhanced Small Device Interface) disk family and Industry 
Standard Architeciure (ISA) disk controller Each of ihe new 20-Mbyte/s disk drives 
from DMD provides up Id 670 Mbytes of 16 ms average access lime storage at an 
MTBF (mean time beiween failures) of 150,000 hours. Adaptec's controller noi only 
supports the drive's data rate, but also provides a 64K-byie read-ahead cache By 
continuing to read data past Ihe user's request, ihe controller's cache already has 
additional data Ihe user is likely lo warn later. At us mtroduciion. the Vectra 486's 
storage subsystem provided excellent performance, capacity, and reliability while 
slaying PC-AT software compatible 

The engineers at CPCD realized Thai although powerful for its time, the ISA disk 
subsystem's performance had approached lis architectural limits Further perform- 
ance improvements could only come with fundamental design changes. Unlike ISA 
disk subsystems, a new architecture would take full advantage of ihe EISA I/O bus 
and other new technologies 

The firsi products based on this new architeciure appeared with the introduction 
of the Vectra 486/33T. Targeting once again the multiuser UNIX operating system 
environment and Novell Netware file server customers, the advanced storage 
learn brought to market the PC industry's first EISA SCSI-2 storage subsystem 
Contributors from all disciplines in ihe PC industry supplied state-of-the-art compo- 
nents Hardware suppliers developed the FJSA SCSI host adapter and Ihe 
440-Mbyie to 1000-Mbyte SCSI-2 disk drive family while software suppliers 
created ihe industry's first tagged queuing SCSI-2 disk drivers for the Santa Cruz 
Operation UNIX operating system and the Novell Netware network operating 
system 

Tagged command queuing is a feature of SCSI-2 that allows a peripheral to intelli- 
gently execute 1/0 requests from Ihe host computer The peripheral can, but does 
not have lo. reorder the sequence of the I/O command stream to optimize its ex- 
ecution. By use of the queue tag, the peripheral can associate the I/O request with 
the daia, thereby nut requiring that the data be associated with a single pending 

'UNIX 15 a U S registered irademark ot UNIX System laboratories in the U S A anil other 
countries 
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Return 
Order 



10 = I 0 Request 
Tag = Queue Tag 

Fig. 1. Tagged queuing 

I/O request Fig 1 illustrates this concept Five 1/0 requests are generated all at 
once in the sequence shown The peripheral device decides to reorder the re- 
quests for opiimal execution and gives the completed requests back to the host 
adapter m Ihe optimal order. The host adapter associates the relumed daia with 
the conect lag, and reassembles the 1/0 thread originated by ihe system 

From the 32-bit bus master host adapter, which supports up to 10-Mbyte/s single- 
ended fast SCSI, lo the 12-ms access time caching disk drive. Ihe hardware com- 
ponents represent some of the best of today's technology applied to Ihe PC envi- 
ronment However, choosing the highesi-performance components is only part of 
ihe development story Tuning each subsystem component for UNIX and Netware 
application performance made the Vectra 486/33T more than the sum of its parts. 
The team optimized each of SCSI-2's performance parameters and features while 
staying within ihe industry standard Additional HP proprietary performance tuning 
of the drive's l28K-byte cache further enhances system performance 

Today's PC SCSI subsystem offering is just the beginning. The architecture can 
support a wide variety of SCSI peripherals available industry-wide For ihe first 
lime PC cusiomers can have access to such diverse peripherals as CD-ROM, lape. 
DAT. and removable magnetaoptical storage. In addition, this EISA SCSI architec- 
ture allows for system performance growth as the industry continues to develop 
SCSI-2 to its full potential The SCSI-2 storage subsyslem architeciure will meet 
the challenge of future customer needs for both added performance and greater 
peripheral connectivity. 

Differentiating products that are based upon widely available industry standards is 
difficult After all, an Intel486 microprocessor runs just as fast tor another PC 
vendor as il does for HP HP's strength lies not only in its SPU architecture but also 
in its ability to fulfill particular customer needs Every Vectra 486 and 486/33T 
storage subsystem has been optimized to provide customers with the best per- 
formance and reliability in an EISA PC. 

Mike Jerbic 
Development Engineer 
California PC Division 
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The physical partitioning »r logic (see Fig. 2a) divides Che 

system iitlt) five printed circuit board assemblies (see Fig. 
2b). The core assemblies consist of a motherboard con- 
taining the core EISA corn nil logic and local I/O logic. 

and two vertical printed circuit assemblies containing tin- 
physical l/( ) connectors for the keyboard, mouse, and 
three I/O ports: two serial and one parallel. These core 
assemblies can be leveraged lot future EISA products. 
The remaining two assemblies are the ("IT and memory 
printed circuit board assemblies. The CPU board contains 
the Intel486 and related control logic, and the memory 
board contains the IIP burst -mode controller and SIMM 
(single in-line memory module) sockets for RAM memory 
upgrade. 



Fig. 2. Logli ai partitioning <>r 
the Vectra 4>*r. system, do Physi- 
ol partiliwiitm Of the Vectra 486 
system 

Product Development Overview 

The time-to-market objectives for the III' Vectra -18(1 prod- 
uct required a new approach lo Hie normal development 
process used Tor past products. Managing three parallel 

technology developments, the Intel486, the EISA bus con- 
troller chips, and lite memory controller, and keeping the 
project on an aggressive schedule was ihe main challenge 
for the IIP Vectra 48(1 team. To add (o the challenge, I wo 
of the three critical technologies ill development were 
outside HP (i.e., the Intel486 and the EISA bus control 
ler). The Inst step was to outline the overall development 
approach that would meet the time-to-ntarket objectives 
with a product dial met our quality Standards, The devel- 
opmenl process also had to be flexible enough lo Hack 
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the parallel development of the Intel4fifi processor and 
the EISA chipset. The resulting development approach 
consisted of two main phases of execution (see Fig. 3). 
Our traditional product development cycle required Ihree 
to four phases. 

We felt we could combine the breadboard and the labora- 
tory prototype phases and still meet all the requirements 
for determining feasibility, design for manufacturing, de- 
sign for EMC. quality, and functional verification in the 
first phase. This approach took less time and cut out 
redundant or ineffective processes. After making the nec- 
essary changes to (he design in the first phase of the 
project, the second phase focused on getting the man- 
ufacturing process ready for volume production and ex- 
ecuting producl qualification testing for IIP environmen- 
tal, regulatory, and quality requirements. 



Many processes were performed in parallel to reduce the 
amount of development time which, in many cases, in- 
creased the risk of having to address dependency prob- 
lems caused by something failing. Other Important pro- 
cesses were put in place to address these potential 
development roadblocks. An example was the establish- 
ment of direct interactive technical communication links 
with outside companies for technical reviews and 
changes. This liaison saved days or weeks of development 
time for the IIP Vectra 486 team. The team also made 
sure that contingency plans were made for the critical 
processes such as printed circuit board layout, fabrica- 
tion, prototyping, and the tools of development to ensure 
that progress would be maintained in most circumstances. 



The IIP Vectra 486/33T 



During the latter stages of the HP Vectra 486/25T development program, develop- 
ment of the Vectra 48B/33T was initiated This system, designed around the new 
Intel486 33-MHz microprocessor, provides higher performance at a lower cost in 
LAN server, multiuser, and PC CAD applications By combining this processor tech- 
nology with enhanced memory and mass storage subsystems and by building on 
the achievements of the Vectra 486/25T, the Vectra 48B/33T program was driven 
by three major objectives fast time to market, higli performance, and high quality 
To meet the challenges of these three objectives, the development team implem- 
ented two key strategies: the first was focused system design understanding, and 
the second was ongoing process improvements 

System Development 

A strategy of the HP Vectra 486 implementation was to partition the system com- 
ponents to provide easy leverage for follow-on EISA products such as a 33-MHz 
system The areas of engineering and product reuse were the package and power 
system, three core printed circuit assemblies, and the video adapter card Through 
performance analysis of the Vectra 486/251 system, we were able to focus on the 
areas that would significantly contribute to our objectives These areas included 
design for 33 MHz. the addition of a high-performance second-level cache, inclu- 
sion of both write and memory buffers, and integration of a new high-performance 
SCSI (Small Computer System Interface) tiard disk subsystem 

To achieve the required performance levels for the 33-MHz system, it was deter- 
mined that a second level cache (in addition to the on-chip Intel486 8K-byte cachel 
was necessary Simulations also showed that significant performance gains could 
be achieved through the addition of a bus write buffer and a memory write buffer 
Therefore, the CPU design includes a 128K-byte, 2-way set associative, write- 
through cache, with one level of bus write buffers In addition, support for an 
optional Wietek 4167 floating-point coprocessor was added to further meet the 
needs of our customers requiring increased floating point performance for their PC 
CAD applications 



Further performance simulation and analysis showed that the capabilities of HP's 
custom burst-mode memory controller, first implemented on the Vectra 486/25T, 
would continue to offer superior peiloirnance. with minor changes for optimizing 
33-MHz operation and with the addition of a memory write buffer Therefore, the 
design of the memory controller was leveraged for use in this higher-performance 
system In fact, the result of the redesign of the memory PCA is a memory board 
that can support both the Vectta 486/25T and 486/33T, with optimal performance 
enhancements for both 

During the Vectra 486/33T design, the team was continuously looking for ways to 
improve the quality and manufacturability of the system A significant contribution 
to this goal was made on the CPU board by eliminating all discrete delay lines. 
This was achieved through the use of delay lines implemented by traces on the 
printed circuit board Using simulation and an understanding of the physical prop- 
erties of the printed circuit board, the team was able to deliver delays with excel- 
lent characteristics and margins This resulted in higher reliability, lower costs, and 
improved manufacturability. 

Process Development 

To achieve the fast time to market, the team needed to apply the lessons learned 
from the efforts of the Vectra 486/25T program In addition to using the improve- 
ments made for that program, several other enhancements were requited To 
ensure team focus, the team constantly reviewed their decisions against the well 
communicated list ol "musts" and "wants" Increased levels of simulation were 
used along with frequent design reviews New and improved processes were 
instituted for supporting the prototype systems used in lest and verification and tor 
tracking and solving defects found during these phases The result of all of these 
efforts was a veiy efficient system verification cycle leading to a timely manufac- 
turing release of a high-quality product 

Mark Linsley 
Section Manager 
California PC Division 



72 OcioImt IWttl llrwk-t! Packard .lemmaj 

©Copr. 1949-1998 Hewlett-Packard Co. 



CPU Design 



Deoug 



HP Vectra 456 
Development 



Pnases 



Roll Printed Circuit 
Board for Production 



Production Manufacturing 
Prototype Release 
Production 
Build and Test "» m P 



Laboratory 
Prototype Phase 



Quality Assurance 
Regulatory and 
Compatibility Tests 



Validation and 
Production Phase 



Manulacturing 
Ramp Phase 



Conclusion 

The Vectra 486 development team was confronted with 
the challenge of bringing an Intcl486-based product to 
market almost simultaneously with the announcement of 
the Intel486 microprocessor. By using new development 
processes, the HP Vectra 486 was the first computer on 
the market using the Intel486 CPU and the EISA bus. 
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The EISA Connector 

Providing backward compatibility in the EISA connector hardware for ISA 
I/O boards resulted in a bilevel connector design that provides pins for 
both bus standards in the same connector. 

by Michael B. Raynham and Douglas M. Thorn 



One nf the reasons for the rapiil growth of the personal 
computer (PC) market is the wide variety of compatible 
software and hardware peripherals available for these 
machines. This compatibility has been provided by a de- 
facto industry -.standard bus specification called Industry 
Standard Architecture (ISA). Although stalled with the 
original IBM PC system architect tire, the standard has 
evolved to where it can be adopted by any PC manufac- 
turer, thus providing a stable platform for software and 
hardware development. 

The EISA (Extended Industry' Standard Architecture) is a 
superset of the ISA S-bil and 16 bit architecture. The im- 
portant features of the EISA Specification include: 
• Full Compatibility with the ISA standard. ISA 8-bit and 
16 btl expansion boards can be installed in EISA slots. 



• Support for a 32-bil address path and for 16-bit or 32-bit 
data transfers for CPU, DMA, and bus master devices. (A 
bus master is a device that drives the address lines and 
controls the signals for a bus cycle.) 

• An efficient synchronous data transfer protocol I hat pro- 
vides for normal single transfers and the cycle control 
required to execute burst cycles up to 33 Mbytes/s. 

• Automatic translation of bus cycles between EISA and 
ISA masters and slaves. 

• Support for a bus master architecture designed for intelli- 
gent peripherals. With EISA-based computers the bus 
controller can operate some of the lines on behalf of the 
bus master. 

• A centralized bus arbitration scheme that supports pre- 
emption of an act ive bus master or DMA device. The 
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EISA arbitration method giants actress to the bus for 
DMA devices. DRAM refresh, bus masters, and bus and 
( IT func tions on a fair, rotational basis. 

• Level-triggered, shareable interrupts. Edge-triggered op- 
eration ensures compatibility with internipt-driven ISA 
devices. Level-triggered operation facilitates sharing of a 
single system interrupt by a number of devices. 

• Automatic configuration of system and expansion boards. 
EISA expansion board manufacturers provide configura- 
tion files and product identification information so thai 
during system initialization these boards can be automati- 
cally configured into a system (see page 84). 

More detailed information about the EISA bus can be 
found in references 1, 2 and 3. 

Engineers from HP's personal computer group were in- 
volved in defining the physical and electrical design of 
the I/O bus, the board connectors, and the logic control- 
ling bus liming for the EISA bus specification. Their most 
obvious contribution was the "double-decker" EISA con- 
nector. This connector has t wo levels of pins. The first 
level maintains ISA compatibility and the second level 
adds the pins for the EISA bus specification. This article 
will describe the EISA connector and some aspects of the 
development partnership that led lo the development of 
the connector and I/O card hardware. 

Background 

The EISA connector was an important part of the imple- 
mentation of the EISA bus standard. At the time we 
started this project there was no connector available that 
met the general electrical and mechanical Characteristics 
required for EISA. Some solutions were proposed but 
they were discarded because they were not competitive in 
size and electrical performance. The IBM MicroChannel* 
bus architecture had already doubled the pitch of con- 
tacts from 0.100-inch to 0.050-inch centers on their con- 
nectors, and it was felt that the EISA solution must use 
this contact density to lie competitive. 

The technical responsibilities for the proposed EISA bus 
tlesign were divided among a small group of the original 
EISA consortium companies. The responsibilities for the 
definition, development, and sourcing for the EISA con- 
nector were given to Hewlett-Packard and Compaq Com- 
puter Corp. 

Because the EISA connector was the first physical evi- 
dence of the EISA hardware, it became important from a 
public relations standpoint that the design not only be 
backward compatible with ISA, but also be perceived as 
technically superior (e.g.. higher-performance, well de- 
signed, etc.). 

The availability of production connectors was a serious 
concern because once the design was finalized the poten- 
tial demand for connector hardware would be very high. 
To ensure thai a high-volume supply would be available, 
and to manage the technical risks, it was decided to re- 
cruit at least two major connector manufacturers to de- 
velop and produce the connector. HP and Compaq Com- 
puter Corp. recruited Bumdy Corporation and AMP 

•MicroChannel is the bus architecture developed to' the IBM Personal Svstem/2 computers 



Incorporated into the EISA consortium lo participate in 
the design. 

Organizational Challenges 

The connector project was managed primarily by a joint 
team of HP and Compaq engineers representing the EISA 
consortium. The team attracted connector manufacturers 
using the number of customers within the consortium to 
convince the manufacturers of the magnitude of the busi- 
ness Opportunity for EISA connectors. The preliminary 
design requirements were established by HP and Compaq 
Computer Corp. as part of the EISA technical Specifica- 
tion. This technical specification, which was revisetl and 
published periodically by the consortium, was the single 
specification lhal all connector vendors used lo develop 
their specific connector designs. The periodic revision of 
the specification proved very valuable in maximizing the 
collective technical contributions of the connector ven- 
dors. All potential vendors could obtain a set of technical 
requirements by joining the EISA consortium. These ven- 
dors could also recommend technical ideas for the design, 
which, if adopted, would become pari of the specification. 
All technical contributions incorporated into the specifica- 
tion became the intellectual properly of the consortium, 
and therefore, became available lo all members. This pro- 
cess produced a very robust and thorough connector 
Specification by using the collective efforts of all partici- 
pants, some of whom were direct competitors. Fig. 1 
shows the design and developmenl information flow dur- 
ing I his process. 

The connector's technical specification was a perform- 
ance-based specification. Except for the basic mechanical 
dimensions, all parameters were specified based on elec- 
trical, environmental, mechanical, or process performance. 
This performance-based approach allowed each vendor to 
provide subtle but significant design features in their final 



Periodic 
Revisions lo the 
EISA Specilicalion 




Fig. 1. Informal ion flow during the design Bid development of 
thi- EISA connector. All connector manufacturers receive.' tie 
EISA bus specification and provided feedback to the EISA 
connector architects without interfacing lo other manufactur- 
ers Tliis provided the best possible technical design without 
compromising vendor confidentiality. 
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EISA Configuration Software 

One of the specifications of the EISA standard defines the pf ocess I o< configuring 
EISA slots into a computet system When the EISA consortium was being formed, 
Comparj Computer Corp started the initial development of the software for config- 
uring EISA slots Soon after development oegan. two HP engineers were assigned 
to work wrrh Compaq in the development effort 

The configuration software detects the presence of accessory cards inserted into 
the EISA slots of me computer and provides a process to configure the cards into 
the system The configuration process begins with the configuration program 
reading a configuration file for each of the accessory cards installed m the EISA 
slots The configuration file contains information about the card that enables the 
program to determine the optimum settings for any switches or jumpers on the 
card Once the program has determined the required configuration of the accessory 
cards, it identifies any manual switch settings or changes that may be necessary, 
and instructs the user to make them The system configuration information is then 
written to nonvolatile memory where it is stored and available to the BIOS (Basic 
I/O Systeml each time the computer boots up. 

HP contributed heavily lo Ihe usability features of the configuration software by 
using a fully equipped camera studio in our usability department to observe people 
using the configuration utility. 

Some of the testing showed that nonprocedural interfaces, such as a windows 
environment, didn't work in the installation process as well as a procedural inter- 
face. (A procedural interface presents a series of steps — procedures — that guide 
the user A nonprocedural interface simultaneously presents a number of tasks 
from which the user must select the next step.l The initial version of the configura- 
tion utility used a windows-like interface. The later versions of the configuration 
utility were changed to use a procedural interface In addition, help screens have 
been improved, and some of the processes have been combined into a single task 
We also improved the code to make ii run faster, eliminating a perception by some 
users that the system was hung up 

The usability testing continues, and the latest version of the configuration soft- 
ware has a much improved user interface. This new interface is fully procedural, 
and tests have shown that even the most inexperienced users can effectively 
configure an HP Vectra computer 

More about the configuration files and the EISA slot initialization process can be 
found m the article on page 83 

Tony Dowden 

Learning Products Engineer 

California PC Division 



connector design. This preserved a healthy competitive 
environment among the connector vendors and allowed 
them to market their individual features and benefits. 

Customer and Vendor Relations 

The existence of (he consortium provided Ihe technical 
benefits mentioned above and il also freed III', Compaq, 
and Other consortium members lo establish the necessary 
customer and vendor relationships I hat would eventually 
be necessary to manufacture products. Nondisclosure 
agreements were established between IIP and several 
connector manufacturers. This allowed HP to negotiate 
supply contracts and characterize their business needs 
independently of any IIP competitors. This provided the 
necessary business and product planning isolation be- 
tween IIP and all other competitors. 

During the development process il was a challenge to 
document and manage Ihe flow of information between 
all parlies. Fig. 2 shows how this was done. Bach PC 
manufacturer was able lo negotiate a supply of connec- 



tors without disclosing volume, pricing, or new product 
schedule to potential competitors. There was no exchange 
of information between connector vendors, and each PC 
vendor had independent access to the connector manufac- 
turers. 

EISA Connector Issues 

The key issues surrounding the development of the EISA 
connector were maintaining ISA electrical and mechanical 
compatibility ai a competitive cost, and excellent market 
perception for the Gnal product. 

Compatibility The compatibility issue meant that Ihe exist- 
ing ISA or PC AT boards had to be supported both elec- 
trically and mechanically in the new scheme. The new 
scheme also had lo support a new EISA board thai used 
Ihe EISA 32-bit burst mode bus. These constraints caused 
rejection of solutions thai required: 
Increasing the height of the worldwide PC AT product 

• packages by 0.3 inch 

Investigating how many PC AT plug-in cards worldwide 

• have components in Ihe 1/S-inch space above the connec- 
tor 

Adding the EISA expansion as a separate outrigger or 

• tandem connector. 

Electrical Performance. The additional EISA signal lines 
were specified by the consortium, including power, 
ground, and spares. This meant adding approximately 90 
pins to those already present on the ISA connector. The 
way in which they were added was important because 
the goal was not only to provide for Ihe additional EISA 
pins, but also to improve the RF performance of the ISA 
section to work with TTI. bus logic having typical logic 
transition times of 2 ns. Improving RF performance meant 
that the connector impedance had to match the typical 
multilayer printed circuit board trace impedance of lid 
ohms, and multiple-line switching Crosstalk to a victim 
line had to be less than 20% at 2 ns. 1 Crosstalk perform 
ancc is largely determined by the ratio of the number Of 
signal pins to the number of ground pins and the isola- 
tion provided by Ihe EISA printed circuit board ground 
plane. Therefore, Ihe EISA connector had to have a lower 




Information Flow 

Fig. 2. information flows lirtwivn PC manufacturers anil 
Connector rnnmifnc.l.urcrs. The Real here was In enforce confi- 
dentiality between the onnnccitir manufacturers and each PC 

vendor they worked with 
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ISA E<pansion Board 




Fig. 3. ['onions of ISA giid EISA expansion boards, showing the 
l/o pins on each board and ;i cutaway view of the EISA connector. 



signal-to-ground pin ratio than an ISA bus because tho 
ISA and EISA signals together form a high-performance 
bus. (ironnd planes were assumed 10 he present in the 
motherboard and EISA printed circuit boards, and the 
current capacity of the ISA contacts had to be 3A per 
contact for ISA power pin compatiblity. 

Mechanical Performance and Market Perception. A positive 
public perception was important to the acceptance or the 
new EISA standard. The connector design needed to 
maintain the reference features, sealing planes, and inser- 
tion force of ISA boards. This was key to the overall me- 
chanical design and it also communicated ergonomic 
backward compatibility to the user. For this reason it was 
decided that the EISA connector should have the same 
dimensions as the ISA connector. 

EISA Connector Solution 

The solution that meets all of the objectives is an exten- 
sion of an idea used from the very first scheme pro- 
posed — tin* double-decker (or bilevel) connector. Instead 
of adding the EISA signals in front of, on the side of, or 
underneath (by increasing the height) of the ISA connec- 
tor, the additional signals were added below the level of 
the existing signal pins (see Figs. 1. and 5). Incidental- 
ly, this solution was arrived at simultaneously by IIP and 
Burndy Corporation. 

At IIP this solution evolved from investigating how to add 
grounds to the ISA connector section for use with EISA 
cards. It was determined that the additional grounds 
could be located on a lower level than the ISA contacts. 
Since the ground contacts had to be as reliable as the 
signal contacts, the EISA signals were also located on the 
lower level (see Fig. :l). 
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EISA Access Key 




Fig. 5.* Inside vii'» of one hall 
of an EISA connector. The EISA 
800688 fay prevents ISA boards 
from being inserted to the depth 
of the EISA contacts. 



"the pictures ul the EISA connector sections shown m Figs <l and 5 were made from 
connectors manufactured bv Burndy Corporation 



Since this design allows eisa signals (including grounds) 

in Hit' saint' motherboard space as an ISA system and the 
connector remains the same height, the signal-io-ground 
pin ratio Tor the ISA signals is effectively reduced to fcl. 
Unproved isolation for the S.:Ci-MIIz BCLK (backplane 
clock) is provided by adjacent RF grounds. T\v<> of the 
ground pins are al BCLK so thai the gold rmger pails are 
on opposite sides of the printed circuit board. Thus these 
pins can be directly connected lo Hie plug-in board 
ground plane with a low-inductance connection. 

In addition, the internal ground planes of the plug-in 
board under the gold lingers, which play a key role in 
determining overall connector electrical performance, can 
extend almost to I he surface of the motherboard. These 
help provide electrical isolation between the two halves 
of the connector, single-line crosstalk between adjacent 
pins of 5% to 7% al 1-ns edge transition limes, and a con- 
trolled ~>r>-ohin lo l'). r .-ohni signal impedance. 1 An added 
benefit of the dual level contact structure is that although 
the number of contacts doublet), the insertion force only 
increased from 28 pounds for the ISA connector to 35 
pounds for the EISA connector The signal density of 
each level is the same as the ISA cotineclors (20 per 
inch I. thereby minimizing the impact on printed circuit 
board manufacturing requirements. 



Conclusion 

Through a joint effort with other members of the EISA 
consortium, we designed a conneclor thai meets all the 
technical design requirements necessary for Industry ae- 
ceptance. (iiven Ihe number of companies and parties 
involved, we achieved an extremely fast development 
Cycle of six months from Star! Of Ibis project lo the pro- 
duction of the first connectors. 
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The HP Vectra 486 Memory Controller 



The memory subsystem architecture and the memory controller in the HP 
Vectra 486 personal computer provide a high-performance burst-mode 
capability. 



by Marilyn J. Lang and Gary W. Lum 



liming the investigation phase for the HP Vectra 486 per- 
sonal computer, in-house performance tools confirmed 
that the memory system was a key to overall system per- 
formance (see article on page 92). Selecting an optimal 
memory and controller architecture fe? a high-perform- 
ance memory subsystem was a major design consider- 
ation for the IIP Vectra 486 design team. 

While performance was considered important to the suc- 
cess of the IIP Vectra 480, it was but one of many impor- 
tant factors to consider for the memory controller design. 
The PC server markcl (a target Tor the IIP Vectra 48G) 
continues to demand more memory, yet entry, level sys- 
tems require a small starling memory and incremental 
memory size. There is also an emerging need to simplify 
the installation and configuration of memory by both cus- 
tomers and dealers. We were also anticipating future In- 
tel486 microprocessor speed upgrades, and wanted a 
memory architecture that could support these upgrades 
with minimal changes. And, of course, we were striving 
to deliver, at a competitive piice, a system that included 
the EISA standard. 

From these requirements, the memory controller objec- 
tives hecame the desire to: 

Meet the IIP Vectra 486 schedule and cost structure 
Provide competitive performance for 25-MHz systems 
Have a large and logical memory upgrade scheme 
Provide a design for supporting higher-speed Vectra 486 
systems. 

With these objectives, the design team began investigating 
relevant technologies that would help determine the opti- 
mal feature set. Three main areas were focused on: the 
Intel486s burst-mode capability, the 4M-bil DRAM, and 
the emerging 36-bit SIMM (single in-line memory module) 
standard for PCs. 

Investigations 

The Intel486, with its on-board 8K-byte cache, uses hurst 
mode to fill a cache line from an external memory sys- 
tem. Burst mode, long used in larger computer systems 
but new to personal computers, is a more efficient meth- 
od of transferring data. Rather Than transferring only a 
single piece of data for each address generated, burst 
mode allows multiple pieces of data ( typically four 
dwords*) to be transferred for each address. Since subse- 
quent addresses need not be generated, fewer cycles are 
required to move information, and bandwidth increases. 

•32 bits 



Supporting burst mode, on the other hand, requires more 
complexity than traditional memory or cache controllers. 

Using our available performance tools, the Intel486 burst- 
mode capability was matched with various memory archi- 
tectures, ranging from a simple, single-bank memory array 
to a cached, multiple bank configuration. The single-bank 
memory array was quickly dropped, because it was not a 
competitive solution. The key finding from this analysis 
was that for 25-MHz systems, by using the burst-mode 
capability in the Intel486, a DRAM memory controller 
communicating directly to the Intel486 could compare 
Quite favorably with a moderately sized external memory 
cache. This was particularly true for cache controllers 
that only supported hurst mode between the Intel486 and 
the cache (or did not support burst mode at all). When 
the cost of the cache was factored in, the interleaved, 
bursting memory controller was the clear preference for 
the Vectra 486. 

The IM-bit DRAM was scheduled for production about 
the same lime the Vectra 486 was to be released. Al- 
though the 4M-bit DRAM would provide the highest 
memory density available, it was considerably more costly 
than the IM-bit DRAM, which had been in production for 
several years. Being able to support both densities would 
allow us to exploit both the IM-bit and 4M-bit advantages. 
Standard memory configurations could be built with the 
cost-effective IM-bit DRAMs, while large memoiy arrays 
could use the 4M-bit. Furthermore, as the 4M-bi1 DRAM 
progressed down the production cost curve, we could 
move quickly to it when prices became attractive. By 
working closely with some of our key memory vendors, 
we were able to secure prototype and production vol- 
umes of 4M-bit DRAMs for the Intel486. 

Previous HP personal computers had used SIMMs, and 
the general feedback from our customers and dealers was 
very positive. A SIMM is a small printed circuit board 
w ith memory installed on it (typically surface mounted I. 
An edge connector on the SIMM allows a customer to 
install it easily into an available connector. The typical 
SIMM organization is nine bits wide (eiglu data bits and a 
parity bit) and the edge connector has 26 pins. During 
Intel486 development a new SIMM organization was be- 
ginning to get attention — 30 bits wide with a 72-pin edge 
connector — which allows a full dword (32 bits plus par- 
ity) to be on a single SIMM. This SIMM also supports 
presence detect, which encodes the size and speed of the 
module on four of the 72 bits, and allows the module 
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characteristics to be read directly from the SIMM. The 
new SIMM was already available in lM-byte and 2M-byte 
densities. Both densities use 1Mbit and 256K-bit DRAMs, 
but at the time none used the 4M-bit DRAM. Working 
with our key memory vendors, we were able to establish 
standard 4M-byte and 8M-byte SIMMs. 

From these investigations and other discussions, the In- 
tel486 memory controller feature set was defined to in- 
clude: 

Intel486 burst-mode support 

2M-byte to 64M-byte memory array size 

Minimum memory upgrade size of 2M-bytes 

Support for 1Mbyte, 2M-byte, 4M-byte, and SM-byte 

SIMMs 

Support for shadowing or remapping of 16K-byt.e memory- 
blocks 

Full support for EISA devices, including bus masters. 

Since many of the features we wanted to include involved 
new technologies, no commercial memory controllers 
were available that supported our feature set. Further- 
more, a short investigation concluded thai using an exist- 
ing memory' controller with additional surrounding logic 
to support the new features would not meet our cost or 
performance goals. We decided I hat the bcsl design ap- 
proach was to develop a new controller using an ASIC to 
implement the memory controller. 

Memory System Architecture 

The memory system is completely contained on a 5.6-inch 
by-i;J.3-inch memory board, and uses a proprietary con- 
nector on the Vectra 48(> motherboard. The memory sys- 
tem sits directly on the 25-MIIz lnlel4S(i bus. 

Allocating board space for the memory conl roller, the 
DRAM drivers, and other support logic, a maximum of 



eight SIMMs can be accomodated on the board. When 
populated with 8M-byte SIMMs, this allows a maximum 
memory size of 64M bytes. This is four times what pre- 
vious HP personal computers had supported. 

In burst-mode operations, the Intel486 is capable of ac- 
cepting one dword each processor clock cycle. At 2-5 
MHz. this means an ideal memory system would be able 
to deliver one dword every 40 ns. Since we were using 
80-ns DRAMs. a simple :J2-bit memory array was clearly 
not sufficient to meet our performance goals. Two possi- 
ble architectures were investigated: a 128-bit-wide 
memory array and a 64-bit-wide memory array. With a 
128-bit memory array, all four dwords would be fetched 
on the initial Intel486 memory access, and one dword 
output on each of the four clock cycles. For the 64-bit 
memory array, two dwords would be fetched using the 
Intel486-gcnerated address, and two more dwords fetched 
using an address generated !>y the memory controller. The 
additional address generation requires another cloc k 
cycle, so the 64-bit memory array provides four dwords in 
five clocks, rather than four clocks. Although this was 
slower than ideal, the 64-bil-wide memory system allowed 
a minimum system configuration and upgrade increment 
of 2M bytes, rather than the 4M bytes required in the 
128-bit architecture. We decided the (vl-bit-wide memory 
array provided the best overall solution for the Vectra 
486. 

Fig. 1 shows the block diagram of the Vectra 486 memory 
system. The 36-bit SIMMs are organized in pairs, creating 
the 64-bit-wide memory array. SIMMs 1, -i, 5, and 7 con- 
tain the lower-order dword, while SIMMs 2, 4, 6. and 8 
contain the higher-order dword. Each SIMM pair must be 
of the same SIMM density, but different density pairs are 
allowed in the memory array. The memory array is fur- 
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ther divided inlo upper and lower memory halves (UP- 
PER_MD and LOWER, MD) to reduce Ihe maximum capaci- 
tance on each memory data line. Although this increased 
part count on the board and loading on the system host 
bus, it improved timing margins in the the most critical 
system timing paths. 

Data transceivers are used to move data between the 
Intel486 and the memory array, and sit directly on Ihe 
system host data bus (HOSTDATAI310)). Since the 64-hii 
memory system requires two memory accesses for each 
Intel486 burst access, latching data transceivers are used 
to output data from the first fetch while the second 64 
bits are read. 

The generation of memory addresses and control signals 
by the memory controller is complicated by the organiza- 
tion of the SIMMs. The lM-byte and 4M-byte SIMMs are 
organized as a single block of memory (or memory bank), 
256K deep by 36 bits wide and 1M deep by 36 bits wide 
respectively. Each memory bank has one row address 
strobe and four column address strobes (one for each 
byte). The 2M-byte and 4M byte SIMMs, however, are or- 
ganized as two banks of memory. The 2M-byte SIMM con 
tains two lM-byte banks, and the 8M-byte SIMM contains 
two 4M-byte banks. These two-bank SIMMs have two row 
address strobes (one per bank) and four shared column 
address strobes (to select one of four bytes in both 
banks). A SIMM socket can contain either a one-bank or 
a two-bank SIMM. 

To correctly control the one-bank or two-bank SIMMs, the 
memory controller generates row address strobes and 
row addresses to the array based on the memory bank 
configuration. Each SIMM pair contains either one or two 
banks, depending on the SIMM installed. Eight row ad- 
dress strobes (RAS(7:0I) are generated directly from the 
memory controller, two for every SIMM pair. For a 2M- 
byte or 8M-byte SIMM the memory controller uses both 
row address strobes. For a lM-byte or 4M-byte SIMM 
only one address strobe is used. The row address appears 
on MA(9:0I when the row address strobe goes active. 

The memory controller also takes advantage of the page 
mode capability of the SIMMs, and keeps the row address 
strobe asserted in each memory bank. If a subsequent 
memory access falls within an active page (has the same 
row address as a previous access to the bank), the much 
faster page mode access is performed. 

The column address strobe and column addresses to the 
array are generated from the four column address strobes 
from the memory controller (SCAS(3:0|), providing one 
strobe per SIMM pair. Because the Intel486 can operate 
on a single byte of data, each byte in the array is made 
individually accessible. Each SIMM has four column ad- 
dress strobes, so 32 strobes (CAS(31:0)) are generated for 
the eight SIMMs by combining SCASI3;0I with eight byte 
enable signals (BE(7:0I). BEI7.0I is also used to generate the 
direction controls (READ_0E and WRITE_0E) and latch signal 
(LATCH_DATA) to tlie data tranceivers. 

Parity is also handled on a byte basis. Because of 
memory controller pinout and timing, parity generation 
and detection are implemented using PALs and random 
logic. Another PAL is used as a SIMM presence delect 



encoder, which reads four presence deteel (PO) bits from 
the first SIMM of each pair and encodes them into six 
SIMM^CONFIGURATION bits. This encoding specifies several 
different possible memory configurations, including com- 
binations of IM-byte and 4M-byte SIMMs, or 2M-byte and 
8M-byte SIMMs. When used with the EISA configuration 
utility, the presence detect capability allows the user to 
configure memory front the screen. 

To accommodate the Intcl486's 33-MHz timing (which was 
not available during the design phase of the project ), Ihe 
READ_0E signals to the data tranceivers are generaled one 
clock early and pipelined through an external registered 
PAL. This scheme ensured that the read path was as fast 
as possible. It also gave us some flexibility in host bus 
timing, in case of changes in CPU timing. 

Memory Controller Architecture 

Fig. 2 shows a block diagram of Ihe Vectra 48(5 memory 
controller. There are seven major blocks in the memory 
controller. The configuration registers contain address 
range, remap and shadow regions, and other memory con- 
figuration information typically set by the BIOS at power- 
on (see Ihe article on page 83). The 8-bit XD bus, a data 
bus available on all PCs, is used to access all memory 
controller registers because fast access is not a high 
priority at power-on time. 

The memory configuration information, along with the 
SIMM configuration information from Ihe presence deled 
pins on each pair of SIMMs, is used by the address block 
to determine if the current memory cycle on Ihe host 
address bus is in the memory controller's address range. 
If it is, the address block will also determine which 
memory bank is selected, whether it is a page hit or miss 
(whether Ihe current row address is the same as an ac- 
tive page), and the appropriate DRAM row and column 
addresses ( MA(9:0)). 

Memory cycles thai appear on the host bus are generated 
either from Ihe CPU or from a backplane device such as 
an EISA bus master. Two independent state machines. Ihe 
CPU state machine and the EISA/ISA/Refresh stale ma- 
chine, monitor the state of each device. The CPU state 
machine is actually two interlocked stale machines. One 
machine monitors the host bus and when it sees a 
memory request, it starts a second slate machine. The 
second machine generates Ihe appropriate CPU_CYCLE_CNTL 
signals (page hil or miss, dword write, or one, two, or 
four dword read). The CPU state machine is fully syn- 
chronous with the Intel486 processor dock. 

The EISA/ISA/Refresh stale machine generates control 
signals for all other cycles. This machine supports EISA 
burst read or write cycles. EISA- and ISA-compatible 
DRAM refresh, and all ISA cycles. Because ISA is an 
asynchronous bus, the EISA/ISA/Refresh state machine is 
a semi-synchronous state machine, and uses BCLK (the 
backplane clock), and external delay lines to generale ihe 
BACKPLANE_CYCLE_CNTL signals. 

The CPU_CYCLE_CNTL and BACKPLANE_CYCLE_CNTL signals are 
generated on every memory cycle. Each set of signals 
includes Ihe BRAM timing relationships thai optimize the 
respective CPU or backplane device bus cycle. HLDA (hold 
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acknowledge) is used as the select signal to 8 mulliplexer 
to determine the correct set of signals. Once the correct 
CYCLE_CNTL is selected, the corresponding DRAM control 
signals RAS. CAS. and WE are generated for each hank via 
the DRAM interlace hlock. The byte. word, and dword 
addressability of the memory array is also handled by the 
DRAM Interface block, which generates the appropriate 
data transceiver control signals (READ.OE and WRITE_0E). 
For the Veclra 48ti, all memory reads are l>4 bits while 
memory writes can be one byte, one word (two bytes), or 
one dword (four bytes). 

The row address strobe timeout clock is used for DRAM 
liming. The maximum lime a page can be open (RAS ac- 
livci is 10 (is. Since it is possible to exceed this Limit 
during an EISA burst cycle, continuous page hits, or a 
long Intel486 idle lime, it is necessary to monitor ihe lime 
each bank is active. Eight timeout counters, one for each 
bank, monitor the active page lime. Counters are enabled 
when the row address strobe is active, reset when the 
row address strobe goes inactive, and clocked by an ex- 
ternal 1.1G-MII/. oscillator. When the timeout limil is 
reached, RAS.TIMEOUT is generated. The CPU state ma- 
chine and the EISA/ISA/Refresh slate machine will Ihen 
finish Ihe current memory cycle and allow the DRAM 
interface block to disable the (imcd-out DRAM page. In 
sonic instances it is possible to disable a page without 
incurring any clock penalties because a page hit on one 
bank can be done while lurning off a timcd-oul bank. 

The test block is used to debug and lesl Ihe memory con- 
troller chip. An external lest pin puts Ihe memory control- 
ler into Ihe test mode. In lest mode, external address 
lines are used to select which signals and stale machine 
Stales are put on the internal lest bus. The internal tesl 
bus contents are available via Ihe XD bus. 



Burst Mode Read 

All Intel486 memory requests are initialed by placing the 
memory address on the host address bus, setting appro- 
priate control lines (i.e. memory read or write) and strob- 
ing ADS*. Fig. 3 shows some of the key liming for a burst - 
mode read cycle for four dwords. One of the control 
lines, BLAST* (burst last) is asserted if Ihe Intel48(i re- 
quests a hurst -mode cycle. If the memory system is inca- 
pable or supporting burst mode, it will return a single 
dword ;md assert RDY* (ready). If Ihe memory system can 
support burst mode, it will assert BROY* (burst ready) and 
return two or four dwords depending on the type of In- 
tel486 request. The Inlel486-generated memory address is 
used to fetch the first two dwords, and a second address 
(incremenled by two dwords) is generated by the memory 
controller to complete the four-dword burst read. 

Reluming a bursl-mode request emails several operations 
within ihe memory system. F'or simplicity, we assume a 
DRAM page hit (for a page miss, additional cycles are 
re<|iiired to generate a row address strobe and row ad- 
dress). When the Intel486 requests a burst cycle, it will 
output an address for each of the four dwords in the 
burst. These addresses (and respective data) follow a 
particular sequence, depending on the initial address sup- 
plied by Ihe Intel486. The memory controller uses only 
ihe initial address because the subsequent addresses from 
ihe Intel486 would not meet our system timing. The 
memory controller will latcll the initial address and gener- 
ate ihe identical sequence earlier in the burst cycle. 

There are four possible address sequences, determined by 
Ihe stale of H0ST__ADDRESS(3:2): 
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xx = H0ST_AD0RESS<31:4| 

00, 01. 10, 11, = HOST_ADDRESS(3:2|or A3 A2 

The memory controller will generate the correct address 
sequence by toggling A2 on each dword. The third and 
fourth dwords differ in A3, so the second memory read 
has a column address that differs from the first only in 
one bit. 

To improve burst-mode timing, rather than waiting for 
BLAST** to be asserted (which may come relatively late in 
the cycle), the memory controller assumes every memory 
read is a burst-mode read, and begins generating CAS. 
READ OE and BRDY* signals. The memory controller will 
return BROY* with the first dword of every read cycle. The 
memory controller will then use BLAST* (now valid) to 
determine if the request was for a burst read. If it was 
not, a RDY* will be generated, the second dword read ig- 
nored, and the cycle terminated. If it is a burst read, then 
CAS is precharged in preparation for a second memory 
read, the first and second dwords are latched in the data 
transceivers, and the second dword is output. BRDY# is 
relumed for the second dword on the next clock cycle, at 
which time the second memory read begins and the first 
data latch is opened lo receive data for the third dword. 



One clock later, both data latches are open, and the third 
and fourth dwords are put on the host data bus in con- 
secutive clock cycles. The memory controller completes 
the burst-mode read by generating a SERDY0* (shared early- 
ready) signal. This signal is input lo a logic block in the 
Veclra 48(5 memory subsystem which forms the RDY* sig- 
nal to the Intel486 (see Fig. 1). In the Intel486 a burst 
mode read cannot be prematurely terminated, so once a 
burst sequence has started, all four dwords must be read. 

Conclusion 

The memory controller design began at the same lime as 
the HP Veclra 486 SPU (system processing unit), and re- 
mained the critical path component for most of the devel 
opmcnt schedule. The project team successfully met the 
IIP Vectra 486 schedule objective by delivering a fully 
functional first-pass memory controller chip. This chip 
revision was used for the HP Vectra 4S6/25T production 
until introduction of the HP Vectra 486/33T memory con- 
troller version. F'ig. 4 shows one of the memory bench- 



Syslem External Cache Size 

Vectra 486 Vendor A Vendor B Vendor C 
None I28K-Byte Cache 6«-Byte Cache 128K-Byte Cache 



Lotus Benchmark 
(Relative Perlormancel 



Integer Sort (K Stonesl 



1.00 


1.03 


.97 


1.03 


778.89 


763.55 


782.83 


328.88 



F'ig. 4. Memory benchmarks run on the Vectra 4H6 ami other 
cached Intel486 25-MHz machines. 
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marks run on the HP Vectra 486 and other cached 
25-MHz Intel486-based machines. 
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The HP Vectra 486 Basic I/O System 

An Intel486 processor, the EISA bus standard, and a new memory 
subsystem all required enhancements to the Basic I/O System to ensure 
that the HP Vectra 486 made the best possible use of these new features. 

by Viswanathan S. Narayanan, Thomas Tom, IrvJn R. Jones Jr., Philip Garcia, and Christophe Grosthor 



The Basic I/O System (BIOS) is the lowest-level software 
interface between the hardware and the operating system 
in the HP Vectra 186 personal computer, The BIOS con- 
sists of a power-on self-test and function support for the 
DOS operating system. The power-on self-test performs 
teslittg and initialization of the various components of the 
system and loads the operating system. The test of the 
BIOS supports Functions to access the various DOS de- 
vices. This article describes the development process and 

the features incorporated Into the HP Vectra 486 Bios to 

support Ihc Intel486 microprocessor and the Extended 
Industry Standard Architecture (EISA). 

BIOS Source Base 

The Vectra 186 BIOS code was heavily leveraged from the 
source code of the Vectra ES, RS, and OS personal com- 
puter series, which support the HP-fflL (human Interface 
link) BIOS extensions (EXBIOS). The EXBIOS support 
was stripped off and support for EISA, the miero-DIN 



mouse, and other enhancements were added to create the 
Vectra 486 BIOS (see Fig. 1). 

To maximize BIOS leverage for future systems, learn 
members focused on keeping a large part of the new 
source files reusable. A common collection of reusable 
software modules ensures a more compatible and easily 
upgradable software system. This commonality ensures 
that during development, potential compatibility problems 
only have to be addressed once, and when a compatibility 
problem in a released product is fixed in a common rou- 
tine, Ihe fix is done once and automatically goes into all 
subsequent software releases. 

The BIOS development of code was shared between the 
engineers at HP's California Personal Computer Division 
in Sunnyvale, California and HP's Grenoble Personal Com- 
puter Division in France. The configuration for transfer- 
ring files back and forth between the two groups is 
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shown in Fig. 2. This rode sharing created issues related 
to ensuring file security and trac king changes to the code. 
For this reason the BIOS source base is managed by a 
software revision control system. The source Tiles are 
Structured into common and machine-specific directories. 
The machine-specific files contain code that handles the 
initialization requirements of different chip sets and differ- 
ent processors and processor speeds. EISA and ISA dif- 
ferences are also handled by the code in these tiles. 

EISA Initialization 

One of the most important features of the EISA architec- 
ture is its ability to delect the I/O expansion boards in- 
serted in the system's motherboard slots. The configura- 
tion utility easy conlig generates information for each EISA 
or ISA card installed in a system expansion card stOt 
When the user is satisfied with the system configuration 
with either the defaults presented by easy config or after 
making any desired changes, the configuration is stored 
in nonviolate RAM. 

The configuration files for each board contain function 
data structures for each slot that provide informal ion on 
the DMA initialization. IRQ (interrupt request) trigger, 
memory information, and I/O initialization, easy config re- 
solves I/O initialization, memory conflicts, and identifica- 
tion for the Individual expansion boards in each slot. 

EISA Configuration Support 

Support for storage and retrieval of EISA configuration 
information is provided by 8K bytes of nonvolatile RAM 
and by system BIOS support routines. The EISA configu- 
ration utility easy config uses Ihese routines to clear non- 
volatile RAM. store EISA configuration information (on a 
slot-by -slol basis), and retrieve information for all func- 
tions of a slot (brief Format) or for one function (detailed 
format). Fig. :j shows some of the processes involved in 
retrieving data from or storing data to the nonvolatile 
RAM containing configuration data. 

The system BIOS power-on software also retrieves the 
configuration data to initialize the hardware in each slot. 
After the system boots, other system drivers, utilities, or 
the operating system may also slore and/or retrieve con- 
figuration data (or any other data) from nonvolatile RAM. 



To accommodate various operating environments lite 
BIOS routines that Interface to the nonvolatile RAM can 
operate in the InteI486's real or protected modes. In real 
mode, 16-bit segments and offsets are used to address a 
lM-hyte address space. In protected mode, segment regis- 
ters become selectors into descriptor tables which with 
offsets allow for Hi-bit to :i2-bit addressing (up to -I giga- 
bytes); 

To save space, input data is compressed by the caller 
before it is stored in nonvolatile RAM by the BIDS rou- 
tines. When configuration data is retrieved from memory 
it is expanded by the BIOS routines before being passeil 
to the caller. Expanding the output data involves padding 
variable-length data fields and blocks into fixed lengths. 
Slot configuration data consists of a variable number of 
variable-length function blocks that describe each function 
or a card in an EISA or ISA slot. The function blocks 
consist of fixed and variable-length fields and variable 
repetitions of fixed and variable-length sublields. These 
fields consist of descriptive text information and memory, 
interrupt, DMA, and I/O resource and configuration data. 
Free-form data can also be stored in some of Ihese fields. 
The slot configuration data is stored sequentially by slot 
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Fig. 3. Storing and retrieving configuration data to and from 
the nonvolatile" RAM I 'tola is compressed when il is placed in 
memory and expanded when it is retrieved. 
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number (including empty slots) until the last physical or 
virtual slot is reached. The minimum size of a slot's con- 
figuration data is zero (empty) and the maximum size can 
be as long as the remaining available space in nonvolatile 
RAM. 

To access nonvolatile RAM data efficiently ( in terms of 
speed :u id space), a table approach is used. A table of 
pointers that point to slot configuration data blocks is 
allocated dynamically and grows inward from one end of 
the nonvolatile RAM. The data space for slot configura- 
tion blocks is also allocated dynamically and also grows 
inward hut from ihe opposite end of nonvolatile RAM 
(see Fig. 4). When the pointer table and data space meet, 
the nonvolatile RAM is full. This technique saves memory 
space and allows for a single look-up to reach any data 
block. 

Power-on Initialization 

When Ihe system is rebooted the BIOS initializes one 
EISA or ISA slot at a lime and one function at a time 
using the configuration information stored in nonvolatile 
RAM. The initialization proceeds in two steps; error 
checking is performed first and then the slot is initialized. 

Error Checking. The system ROM BIOS begins the initial- 
ization only if the nonvolatile memory's checksum is 
good. The BIOS also has to check whether the correct 
card is installed in the right slot before it initializes the 
card in that slot. The BIOS checks for the following com- 
binations in each slot. 

■ A slot could be defined as empty according to the config- 
uration data, but the user may have plugged a card into 
Ihe slot 

• A slot could be defined to have a particular identifier ac- 
cording to the configuration data but may be read as 

empty. 

•A slot eOUbj be defined to have no readable identifier ac- 
cording to the configuration data but Bit >S reads an iden- 
tifier from the slot. 

■ An identifier read from the slot may not agree with the 
identifier in Ihe configuration data. 




•. Conligurallon 
' Data 



Nonvolatile RAM ; 



Growth Direction 
torOMi 



Growth Direction 
lot Pointers 



IFFCH 
IFFEH 




Pointers 



KiK. 4. Organization of pointers and slut ( onfigurarion data in 
nonvolatile RAM. 



An identifier for a slot is checked by reading certain slot- 
specific I/O ports as defined by the EISA specifications. 
After verifying that the slot that needs to be initialized 
has the correct card in it. the BIOS start the initialization 
for that slot. Fig. 5 shows the error checking process 
performed by the BIOS during initialization. 

Slot Initialization. As in error checking, slot initialization 
data comes from the configuration data in nonvolatile 
memory. The configuration data for a slot is retrieved as 
a block of data, anil there could be many blocks of data 
for a particular slot. Fig. fi shows the flow for slot initial- 
ization. 

Slot initialization starts with the BIOS code reading a 
block of data from nonvolatile memory for a particular 
slot. It checks to see if there are any DMA initializations 
for that slot. If DMA is not shared, then the BIOS initial- 
izes die extended DMA registers defined for that slot. 
Next the code checks to see if ihe slot has any IRQs that 
need to be set as edge- or level-triggered. It then sets up 
the cac he map for noncacheable regions as defined for 
that slot. The code then continues with the I/O initializa- 
tions if any. Once this sequence is complete ihe code 
continues with the nexl function for the slot until all the 
functions are completed for that slot. 

The BIOS provides a feature that allows the user to make 
blocks of memory cacheable or nol. This is veiy useful 
for boards that have memory-mapped I/O. The BIOS 
builds a cache map in which each bit defines the cache 
on/Off slate of a particular segment (each segment is (i4K 
bytes). A function in the configuration information for a 
slot can define the start address of the memory and Ihe 

length of memory for whi< h caching needs to be turned 

on or off. The BIOS initially sets all segments' caching to 
be on, ll then checks for segments of memory for which 
the caching needs CO be turned off and then lunis caching 
olT for Ihe segments that are wilhin Ihe memory length 
specified. The cache map is updated and is later used in 
the boot process to initialize a (UK-bit static RAM. which 
(he hardware uses in its cache on/off logic. Each bit of 
Ihe sialic RAM represents a segment, allowing (UK seg- 
ments (or four gigabytes) to be represented (see Fig. 7). 

The BIOS then initializes the various I/O pons as defined 
in the configuration data. The I/O can be S-bil. Hi-bit, or 

:)2-bit reads or wriies. The configuration data also defines 
the mask for the particular I/O port. Thus, the VO port is 

read, the data is masked (ANDed) with the mask value. 
ORed wiih the bits thai need to be set. and written back 
t o the I/O port 

Finally the BIOS enables the board in die initialized slot 
Any lime the initialization tails, the BIOS makes sure thai 
the system can boot from a flexible disk and that the 
video is initialized correctly. This is done so (hat the ma- 
chine- is in a minimum working state so that the user can 
execute easy conlig and reconfigure Ihe system. 

Variable Speed Control 

For backwards compatibility, it is sometimes necessary to 
reduce the speed of the PC This is particularly true for 
copy-protected software- applications thai are speed sensi- 
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tive. The Vectra 486 can reduce its speed for all opera- 
lions, or only for flexible disk operations. The system 
BIOS is responsible for this control. To change speeds ihe 
BIOS programs the duty cycle of a square wave generated 
by a hardware tinier which modulates the Spd_Hold_Req 
(hold request) input of the microprocessor (see Fig. 8a). 

If the microprocessor did not have an internal cache then 
it would effectively be idle while it relinquishes the bus 
during a hold requesl. Its effective speed would thereby 
be reduced by lite modulation factor. Since the Intel486 
has an internal cache il will continue execuiion. even 



when in a Hold state, until a cache miss occurs, when il 
must wail for the bus. Therefore, to control the micropro- 
cessor's effective speed accurately when it is reduced 
from its maximum (unmodulated) value, it is necessary to 
disable and flush Ihe processor's internal cache. With its 
internal cache empty, the processor will halt execution 
(because of cache misses) until the modulated 
Spd_Hold_Req signal is dcasserted. The BIOS programs an 
I/O poll which disables and Hushes the internal cache via 
the Intel486 control lines. This avoids having to use the 
Intel486 control registers to disable Ihe cache. These con- 



86 ttaoberlMl Ili'wk'it-I'ai karcl.lcmnml 

©Copr. 1949-1998 Hewlett-Packard Co. 



MUM £iUf*SM oiu 



Set IRQ lor Edge 
O* level Triggennj 




Stt Ciche Hap 10 Indicate 
Region thai Are not Ciehed 



Ibtk 10 Port Dili with 
Contlgurallon Mitk vilue 



Fig. 6. Plow lor slut Initialization, 

I ml registers ronlcl be in use by other soli ware applica- 
tions and might be disrupted by the actions of the BIOS. 

II" the speed is restored, or after a flexible disk access 
when at autospeed* the BIOS reprograms the cache con- 
trol I/O port and the duly cycle of the square wave (see 
Fig. 8b). Therefore, the control stale of ihe cache is main- 
tained after resumption of maximum speed without inter- 
fering with resources (Intel486 control registers) that ap- 
plications may depend upon. 

Micro-DIN and Security Features 

The input system consists of three components: the input 
devices. BIOS functions, and the Intel 8042 keyboard con- 
Iroller. The 8042 keyboard controller communicates with 

"Al autospeed the system operates at its highest speed unmodulated and switches lo an 
effective speed o!8 HHj Imoduiated only when it is accessing a flexible disk 



the keyboard and an auxiliary de\ice in a bidirectional, 
serial format with a synchronized clock generated by the 
input device. The auxiliary' device may be any type of 
serial input device compatible with the 8042 keyboard 
controller interface. Some of these are: mouse, touchpad. 
trackball, and keyboard. 

The 8042 keyboard controller receives the serial data, 
checks the parity, translates keyboard scan codes (if re- 
quested), and presents the data to the system as a byte 
of data. It also provides a password security mechanism 
to support the network server mode and application soft- 
ware. 

Additional security features of the Vcctra 48(5 PC are the 
power-on password and the mechanical keylock. Both 
schemes are designed lo prevent unauthorized access to 
the PC. The BIOS provides the software to support the 
power-on password feature whenever the Vcctra 486 is 
powered on. 

The password function can be configured via the easy 
config utility lo request a password cither when the PC is 
powered on, or only when a user needs lo use the input 
devices. If Ihe PC is configured to request a password, 
Ihe BIOS will display a graphical key symbol to prompt 
the user for the password. If the user types in the Correct 
password, the PC will continue with its initialization. 
Otherwise, the BIOS allows three attempts for the user to 
type in the P as s wor d before hailing the CPU. If the user 
knows the correct password, the BIOS will allow the user 
to change or delete the password during the power-on 
sequence. 

When the password is set up lo allow limited access, 
which is also known as the network server mode, all mi- 
cro-DIN input devices are disabled via the 8042. A PC 
configured as an unattended file server would typically 
install the password in the network server mode. In the 
network server mode, if Ihe BIOS detects a diskette in 
drive A, it will prompt the user for the installed password 
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because an unauthorized user may be trying to gain ac- 
cess to the PC via a bootable diskette. 

The mechanical keylock, used for locking the input de- 
vices, can be used in conjunction with the power-on pass- 
word to provide maximum security. If the keylock is in 
the locked position and the password function is installed 
to request the password at power-on, then the user will 
have to unlock the keylock before typing the password. 
Bui if ilte password function is installed in the network 
server mode, the keylock doesn"! have to be unlocked lo 
type in the password until a user needs lo use the input 
devices. 

Since the user may occasionally Ibrgel the installed pass- 
word, the BIOS supports a DIP switch within the Vectra 
•ISfi that disables the password. The BIOS uses this 
switch lo allow the user to erase the password without 
any knowledge of the installed password. This switch is 
also used to forbid the installation of a password by an 
unauthorized user. To access the switch, the user must 
unlock a mechanical keylock to open the PC. 

Shadowing and Remapping 

The system memory of a Vectra 486 is partitioned into 
three areas: base memory, reserved memory, and ex- 
tended memory. The base memory is within the physical 
address range from 0 to 640K bytes. The reserved address 
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space is within the physical address range from 640 bytes 
to 1M bytes. Lastly, the extended memory area is all 
memory above lM bytes. This memory architecture is 
known as the PC AT system memory architecture. 

Most software applications typically use the base area 
and some use the extended memory area The reserved 
memory is set aside for special system functions and is 
generally not available for typical software application 
use. The reserved memory is organized to support the 
main functional components of a microcomputer (see Fig. 
!)). The video display area and the video RAM can occupy 
the lowest portion of the reserved address space, A0OO0 
to BFFFF. The video ROM BIOS can begin at C0000 and 
typically ends at C7FFF. The address space that begins at 
C8000 and ends at DFFFF is reserved lor special I/O 
adapters and memory drivers. FOOOO to KFFFF is used 
for onboard option ROMs or backplane I/O ROMs (lo- 
cated in the I/O slots for ISA or KISA cards). FOOOO to 
KFFFF is reserved for the Basic Input/Ouput System (sys- 
tem ROM BIOS). 

Since the introduction of this architecture, the cost of 
memory devices has declined while the density and speed 
of the components have increased. Processor speeds have 
increased far beyond the speed that any programmable 
read-only memory device can effectively support. With the 
advent of 32-bit bus architectures, systems can physically 
address four gigabytes of memory, which can be used to 
support larger, more complex software applications. 

Better system performance can be obtained with efficient 
management of the reserved memory. The Vectra 486 
makes use of two memory management schemes: ROM 
BIOS shadowing and memory remapping; ROM BIOS 
shadowing is a method used to speed up ROM memory 
access so that portions of reserved memory that are fre- 
quently used can be accessed as quickly as possible. 
Memory remapping permits unused reserved memory to 
be used as extended memory. 

Shadowing. BIOS and video ROM BIOS routines and data 
are stored in EPROM (electrically programmable read- 
only memory). This type of memory is considerably slow- 
er than dynamic random access memory (DRAM). Since 
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the BIOS and video ROM routines are frequently used by 
the system, contents of the ROM BIOS and video ROM 
are copied into memory having a faster access time. This 
technique is known as shadowing. 

The conventional organization of the reserved address 
space, in Fig. 9, shows the locations of the system RAM 
and BIOS ROMs, In the Vectra 486. as in other microcom- 
puting systems, the conventional organization of reserved 
memory' is enhanced to accommodate some additional 
system RAM which is located at the same address loca- 
tions as the system BIOS and video ROMs (see Fig. 10J. 
This memory is called shadow RAM. Another advantage 
of shadowing is that memory fetches for the Intel486 can 
be accomplished four times faster because the EPROM is 
an 8-bit device and system DRAM consists of 32-bit de- 
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The conventional approach to shadowing is to copy the 
contents of the system ROM BIOS and video ROM BIOS 
to some temporary location. The ROM is then disabled 
and the shadow RAM is enabled. THE BIOS information, 
which currently resides in the temporary storage area is 
copied into the shadow memory at the same memory 
address locations from which the information was origi- 
nally retrieved. Following the shadowing process, any 
data that was originally in ROM will be accessed from 
the corresponding location in the faster shadow RAM. 
This approach requires that the state variables of the 
memory controller indicate whether the ROM or the shad- 
ow RAM is being accessed and if write access to the 
shadow memory is permitted. These state variables pre- 
vent data corruption by ensuring that either the ROM or 
the shadow RAM is enabled at any time, but not both, 
and that, once copied, the contents of the shadow 
memory cannot be inadvertently overwritten. 

The disadvantage of the conventional shadowing method 
is that system memory control states are wasted. The 
Vectra 486 overcomes this problem by eliminating the 
ROM and shadow RAM enable variable. The write protect 
and shadow RAM enable variables are combined into a 
single state variable. On power-up, the default state of the 
system will read BIOS (system and video ROM) data from 
ROM and write this data to the BIOS address space in 
the shadow RAM. Whenever the shadow RAM is enabled, 
data read front the BIOS address space will be read from 
the shadow memory and all write operations to addresses 
within the BIOS address space are ignored. The shadow- 
ing method used in the Vectra 480 system results in a 
tremendous savings of hardware and valuable system 
ROM BIOS code space. The additional step of copying 
BIOS data is eliminated since data can be copied directly 
from ROM into the shadow RAM. 

Remapping. It is often the Case that following completion 
of the shadowing process, portions of the RAM in the 
reserved memory area are not used. Since typical soft- 
ware applications are not designed to be able to access 
reserved memory for general storage purposes, the free 
portions of reserved RAM remain unused. A software ap- 
plication can directly access reserved memory, but with- 
out prior knowledge of the configuration of the system. 



the application could unknowingly cause a device to mal- 
function by corrupting sensitive data. One approach to 
this problem is to incorporate an expanded memory man- 
ager into the system configuration. An expanded memory 
manager manages the free reserved memory by allowing 
the application to use the space as additional base 
memory, and makes the system appear as if the amount 
of base memory has been expanded. The disadvantage of 
using an expanded memory driver is that it is used during 
run time. This mode of operation degrades system perfor- 
mance. The expanded memory manager also requires 
memory space for storage of the software routines, there- 
by leaving less memory for the application to use. 

Another conventional method is to remap portions of re- 
served memory to the top of the physical address space 
of the system. The disadvantage of this method is that 
the memory location to which the free memory is moved 
sometimes does not border on existing memory locations 
and results in creating a noncontiguous memory Structure 
Most applications cannot make use of fragmented 
memory. Also, the conventional remapping scheme is a 
machine specific feature, and therefore, all software ap- 
plications must be customized to lake advantage of the 
remapped memory. 

The Vectra 480 solution to memory remapping uses the 
system configuration information in nonvolatile RAM to 
instruct the memory controller how to organize the sys- 
tem memory. As an EISA machine, the Vectra 180 has an 
autoconfiguration program which identifies system compo- 
nents and allocates system resources to obtain maximal 
system performance. 

Memory remapping in the Vectra 486 is a two-step pro- 
cess. The first step is to find the largest contiguous 
chunk of free reserved memory' that can be remapped. 
The video RAM space (A0000 to BFFFF) is generally not 
used because the video cards and the embedded subsys- 
tems are currently made with their own RAM. On-board 
option ROMs, which physically reside at E0000 to EFFFF, 
are rarely used, and the \ideo BIOS address space, COOOO 
to CSOOii, fragments the reserved memory area. The way 
to create the largest contiguous section for reserved 
memory is to shadow the video BIOS in shadow memory 



© Copr. 1949-1998 Hewlett-Packard Co. 



October (991 Hewlett Packard Journal 8» 



at EOOOO, provided thai the system does not contain on- 
board option ROMs and if I/O considerations of the video 
BIOS support portability. This paradigm creates a 25(5 K- 
byte (A0000 to DFFFF) chunk of memory that can be 
remapped (see Fig. 11), The .'12K-byte portion between 
E8QO0 and EFFFF is unused. The system memory control- 
ler is told whal area of reserved memory is lo be re- 
mapped. It must also be noted that systems that use the 
DOS shell rely heavily on I he system BIOS and video 
BIOS routines, so maximally, only 2568 bytes of memory 
is available for remapping. Systems thai use OS/2 and the 
UNIX* operating system ran maximally remap all of re- 
served memory because these operating systems replace 
system BIOS and video BIOS and supply all of I heir own 
drivers. 

The second step in the remapping process is to determine 
where the physical existence of memory ends. The sys- 
tem BIOS knows this information following the system 
memory test procedure during the system power-on self- 
test. This address is passed to the system memory con- 
troller. Following the fits! step, the memory controller has 
the necessary information for memory remapping. The 
system memory controller then does the proper address 
translation. 

BU )S shadowing and reserved memory remapping are 
powerful system features that enhance system perfor- 
mance and make betler use of system resources. BIOS 
shadowing is a common feature among all machines cur- 
rently on the market, lis primary advantage is to bring 
more parity between processor speed and ROM access 
times. To implement this functionality in an efficient man- 

•UNIX is a registered trademark of UNIX System Laboratories Inc. in We U.S.A. and other 
countries 
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ner saves hardware and code space which iranslales into 
a cost savings lo the customer. 

System Memory Initialization 

Finite state machines implemented in soflware can be a 
very powerful tool. For a system's BIOS, a software finite 
state machine is ideal for component test situalions in 
which scratchpad memory is not available. This technique 
is used in testing the system memory configuration in the 
Vectra 48G. 

The memory subsystem of the Vectra 48b is a two-way 
interleaved, linear memory architecture. The system 
memory board has four memory banks. Each bank can 
hold two memory modules. The Iwo memory modules are 
two-way word interleaved. The banks of memory are or- 
ganized in a linear fashion. See the article on page 78 for 
more information about the Vectra 48(> memory subsys- 
tem. 

The memory modules are packaged in single in-line 
memory modules and come in lM-byle, 2M-byte, 4M-byie, 
and 8M-byie varieties. The 1Mbyte and 4M-byte modules 
are single-density modules. The 2M-byle and 8M-byie 
modules are double-densily modules. Each memory bank 
on the system memory board musl contain a pair of 
memory modules thai are the same size and have the 
same density type- Moreover, density restrictions require 
that all memory' banks contain memory modules of the 
same density type. The linear structure of the memory 
subsystem requires thai the amount of memory in a bank- 
be less than or equal lo the amount of memory in a bank 
Ihal logically precedes it. The exception lo this rule is the 
first bank because no other memory bank precedes it. 

Before system memory can be tested, the memory subsys- 
tem configuration musl lie verified. The power-on self-test 
procedure in the system BIOS is responsible for this task. 
The use of system resources must be kept lo a minimum 
because system memory is not available at this stage in 
the system power-on initialization process. A software 
finite state machine is ideal in this situation, since only 
the registers within the processor are available-. The finite 
state control is guided by the memory module identifica- 
tion encoding (each memory module has information en- 
coded within it that specifies the size and density type of 
the module). The memory state machine evaluates the 
Identification for each memory bank and verifies that the 
Current memory configuration (linearity, uniform bank 
densities, etc.) is valid. 

The software finite state method is very effective when 
considering that each of the four banks can have one of 
five types of memory modules. The number of possible 
memory configurations is 4 or 11)24 possible configura- 
tions; Of the 1024 possible configurations, 28 are valid If 
module density errors are found first, then ihe linearity 
check can be clone with a software finite state machine 
with four states. Fig. 12 shows Ihe finite slate machine 
for testing the Vectra 4S(i memory configuration. 
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figuration [eating. 
Defect Tracking 

Because BIOS source code was shared among indepen- 
dently managed projects in different locations, BIOS prob- 
lems had to be tracked not only for the Vectra 48(1 prod- 
uct but also for several other IIP personal computer 
products as will. 

To keep track of prerelease problems across the various 
projects and to provide a means of Collecting more global 
process Improvement metrics, a custom dBASE IV" ap- 
plication was written for use by all of the IJIOS teams. 
Problems reported on the Vectn 486 were sent by testers 
to a special electronic mail account to be entered into 
the database. The use of a standard problem form al- 
lowed the collection of valuable statistical as well as 
problem-Specific information. Information about BIOS 
problems in common files was shared directly with each 
team by exchanging database files. The flexibility of Ihe 
PC database application allowed each leant lo adapt the 
database application to their needs without affecting I In- 
ability to share data. This was important, because several 
BIOS teams could have been involved in resolving any 
one problem. 

As each problem was investigated and resolved, status 
Information was entered into the database. Detailed in- 
formatton, such as which code module contained the 
problem and when the problem was introduced, was 
n-adilv available. The typical weekly status report con- 



tained a simple summary of the active problems, the 
problem owners, and their current status. One BIOS team 
member acted as the bug manager and helped keep ev- 
eryone informed of the progress being made to resolve a 
problem. 

BIOS Qualification and Test 

The BIOS qualification effort for the Vectra 486 project 
was an improvement over previous BIOS development 
efforts. Because of major revisions to the BIOS in the 
Vectra 486 and the need to produce quality software in 
minimum time, a special BIOS qualification team was 
formed. This team consisted of four engineers and a soft- 
ware technician whose main job was to verify thai the 
BIOS specifications were correct In the past, the job of 
qualification of Ihe BIOS was left up to the developer of 
the BIOS code. For the Vectra 486. it was felt that qualifi- 
cation would be mure thorough if the persons developing 
and executing the tests were not the individuals develop- 
ing the BIOS code. 

To make best use of our limited resources, two types of 
tesl strategies were developed: white box and black box 
testing. Black box testing used a high-level language pro- 
gram, such as 0, to verify the functionality and quality of 
the BIOS. The C functions invoked DOS functions, BIOS 
fund ions, and I/O registers to tesl the BIOS. This was the 
standard method of testing most programs. However, 
when testing Ihe BIOS, we did not always have the 
luxury of relying on an operating syslem such as DOS 
because much of the BIOS functionalily had lo be tested 
during the machine initialization, and was inaccessible to 
high-level programs. 

An alternate method was developed using some new ap- 
proaches and working with special development tools to 
perform white box testing. New features such as KISA 
initialization, memory initialization, and shadowing rou- 
tines were tested using I Iris approach. This method forced 
two engineers to read and understand Ihe actual code: 
the original designer and Ihe one developing Ihe lest. This 
task alone required an in-depth understanding of Ihe BIOS 
modules on an instruelion-by-instruclion basis. The con- 
cept of having two people intimately understand each 
module is not new, but typically resource limitations 
make such an arrangement a luxury. 

There were many advantages lo litis type of testing. For 
one thing, il allowed us lo simulate some of Ihe system 
errors. For example, if the user had an invalid memory 
configuration, this error could be simulated without even 
changing the memory Inside the computer. Fiinhcnnore. 
all the valid memory configuration could be lesled via 
this program. There were well over 10(1(1 memory configu- 
rations thai could be lesled through one automated pro- 
gram. Normally, this process would involve a technician 
physically changing Ihe configuralion each lime. Another 
advantage was that the BIOS could be tested without the 
hardware. This proved lo be very helpful since Ihe BIOS 
was being developed before Ihe hardware was available. 
With this method, two tasks could be done concurrently. 
Once the hardware was available, Ihe tests could also In- 
executed on the hardware. 
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The test Strategy thai was developed by the BIOS qualifi- 
cation team enabled Hie leam to perform tests on the 
DIGS that would normally not have been done. Once the 
tests were developed, they could be added to the test 
suite for regression testing and other BIOS related tests. 

Conclusion 

The HI* Vectra 48fi BIOS development effort was a major 
milestone in HP's Personal Computer Groups software 
development tustory from the perspective of both new PC 
technology advances supported and new processes 
introduced Support for new technologies and features 
like the EISA architecture and an advanced memory con- 
troller was incorporated into BIOS with high quality while 
meeting system schedules. 

New or enhanced processes with their associated tools 
were incorporated lo meet customer needs and IIP busi- 
ness requirements. A customized source version control 
process and tools allowed efficient, multi-site, simulta- 



neous PC BIOS development with maximum code reuse. 
Brand new defect tracking and component qualification 
processes and tools allowed quality BIGS development 
concurrent with PC hardware development. 
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Performance Analysis of Personal 
Computer Workstations 

The ability to analyze the performance of personal computers via 
noninvasive monitoring and simulation allows designers to make critical 
design trade-offs before committing to hardware. 

by David W. Blevins, Christopher A. Bartholomew, and John D. Graf 



Today's high-performance personal computers are being 
used as file servers, engineering workstations, and busi- 
ness transaction processors, areas previously dominated 
by large, costly mainframes or minicomputers. In I his 
inarkel. performance is of paramount importance in dif- 
ferentiating one product from another. Our objective at 
HP's Personal Computer Group's performance analysis 
laboratory is to ensure that performance is designed into 
HP's offering of personal computers. To achieve this, anal- 
ysis of a personal computer's subsystem workloads and 
predictive system modeling can be used to identify bottle- 
necks and make architectural design decisions. This ar- 
ticle describes the tools and methodologies used by IIP 
engineers to accomplish performance analysis for person- 
al computers. 

The toolset currently being used at the performance anal- 
ysis laboratory consists of specialized hardware and soft- 
ware. Typically, the hardware gathers data from a system 
under test and then the data is postprocessed by the soft- 
ware lo create reports (see Fig. 1). This data can also be 



used to drive software models of personal computer sub- 
systems. 

Hardware-Based Tools 

The two hardware-based performance analysis tools 
shown in Fig. 1 are the processor activity monitor 
(PMON) and the backplane I/O activity monitor (BIO- 
MON). Both tools are noninvasive in I hat they collect 
data without interfering with the normal activity of the 
system under test. 

Processor Activity Monitor 

The processor activity monitor is a hardware device that 
monitors a personal computer's microprocessor to track 
low-level CPU activity. The PMON is sandwiched between 
the computer's CPU and the CPU socket (see Fig. 2). The 
PMON monitors the processor's address and control pins. 
For each CPU operation, the PMON will track the dura- 
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lion and address of the operation and output the results 
lo the data capture device. 

Gathering statistics on the activities of a personal com- 
puter's microprocessor can be very useful in making de- 
sign decisions about the arrangement of the support cir- 
cuitry (e.g.. cache and main memory, I/O bus interface, 
and bus lines). In addition, trace files that detail the 
CPU's requests to the memory system can be used to 
drive software simulations of various cache memory ar- 
rangements as well as more comprehensive CPU and 
meltioiy or system simulations. 

Two data capture devices are commonly used in conjunc- 
tion with the PMON. The first, an HP 16500 logic analyzer 
configured with Optional system performance analysis 
software, generates two main types of data. One Is a his- 
togram that shows the occurrence mix of a user-do lined 
subset of the possible CPU cycle types (Fig. 3a). The per- 
formance analysis software averages 1000 samples of 
cycles from the PMON on the fly, giving a randomly 
sampled profile of processor activity Ihroughoul the dura- 
tion of a performance benchmark. The second type of 
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data provided by the HP 16500 is real-time calculation of 
the minimum, maximum, and average lime intervals be- 
tween the beginning and end of user-defined events ( Fig. 
3b). The performance analysis software averages the in- 
terval calculations on the fly over a large number of sam- 
ples lo give, for example, the average interarrival lime of 
writes to Video memory in a CAD application. 

The other data capture device used with the PMON is a 
less intelligent hul higher-capac ity logic analyzer. This 
instrument has a !6-megasamplo-deep Irate buffer (as 
opposed lo lhe 1000-saiuple deep buffer in lhe IIP 16600). 
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lb) 

Fig. 3. Sample histograms fr in III' |iir>ll(l logic analyzer, (a) The 

occurrence mix of a subset of liilcl-181'i CPU cycle types, (h) Inter- 
arrival limes of writes to video memory. 
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Address Range 


Number ol 
Occurrences 


°. ol Totals 


Tolal CPU Clocks 


% ol Time 


Average 

AMI 1 HI. 

CPU Clocks 


Interrupt Vectors 


3249 


1.34% 


38297 


1.55% 


11.79 


STD-BIOS Data 


1153 


0.48% 


12340 


0.50% 


10.70 


DOS 


23670 


9.60% 


249800 


10.09% 


10.55 


Application 


197143 


61.59% 


2028358 


81.91% 


10.29 


Video RAM 


24B 


0.10% 


5890 


0.24% 


23.75 


BIOS ROM 


1967 


0.81% 


21284 


0.86% 


10.82 


Extended Memory 


1420B 


5.88% 


120240 


4.86% 


8.46 



Fig. 4. PMON address range 
summary report. 



Cycles from the PMON are captured in this buffer in real 
time and the data is later archived to a host computer's 
hard disk. The huffer typically holds four to five seconds 
of continuous bus cycle activity generated by a 25-Mhz 
Intel486 microprocessor running an MS-DOS'*' application. 
The data can then be used to drive software simulations 
or processed to create summary reports, such as an ad- 
dress range summary of how the processor's address 
space is used by operating systems and application soft- 
ware (see Fig. 4). 

Backplane I/O Activity Monitor 

The backplane I/O activity monitor, or I3IOMON, also cap- 
tures information from a personal computer's hardware, 
but instead of the CPU activity, the I/O activity on the 
ISA (Industry Standard Architecture) or EISA (Extended 
Industry Standard Architecture) backplane is monitored 
(Fig. 5). The BIOMON consists of two backplane I/O 
cards: I he qualify and capture card and the monitor card. 
The qualify and capture card resides noninvasively in the 
SIT (system under test) and is connected via a ribbon 
cable tO the monitor card, which is located in another 
personal computer called the monitor system. The moni- 
tor system receives, stores, and processes the I/O events 
captured on the SUT's backplane. 

During operation the qualify and capture card is loaded 
With capture enable flags for each of the I/O addresses 
whose activity is to be monitored on the SOT backplane. 

Once the qualify and capture card is set up. I/O address 
accesses cm the SUT's backplane cause an event informa- 
tion packet (address, data, etc.) to be transferred to a 
first-in, first-out (FIFO) holding buffer, allowing tor 
asynchronous operation of the SUT and the monitor sys- 
tem. The FIFO is unloaded by transferring each event 
information packet to the monitor syslem's extended 

"MS-DOS is a U S. registered trademark ol Microsoft Corp. 



memory. At the end of event capture, this trace of I/O 
events can be either stored to hard disk or immediately 
postprocessed for analysis. 

One very powerful use of BIOMON is the performance 
analysis of marked code, which is code that has been 
modified to perform I/O writes at the beginning and end 
of specific events within a software routine. The frequen- 
cy of occurrence and execution time for each marked 
software event can then be analyzed under different con- 
figurations to find existing or potential bottlenecks and 
the optimum operating environment. 

As an example, the performance analysis laboratory has 
developed a special installable software filler that writes 
to specific I/O addresses at the beginning and end of DOS 
and BIOS (Basic I/O System) interrupts. For our pur- 
poses, a write to I/O port 200 (hexadecimal) denotes the 
beginning of an interrupt, and a write to port 202 denotes 
the end of an interrupt. The trigger address comparator is 
told to capture data for I/O addresses 200 and 202, and 
any normal application using DOS or BIOS functions is 
run on the SUT. The resulting trace can be postprocessed 
to show which DOS and BIOS routines were used by the 
application, how many times each one was called, and 

how long they executed (Fig. 6a). other information such 

as the inlerarrival time between events, exclusive versus 
inclusive service time for nested events, and tolal time 
spenl in various application arc-as can also be extracted 
(Fig. 6h). Analysis of this information can assist the soft- 
ware engineer in optimizing frequently-used functions in 
DOS and the BIOS. 

This technique can also be used to analyze protected- 
mode operating systems such as OS/2 and UNIX.** How- 
ever, because of their nature, these environments must 

""UNIX is a registered trademark ol UNIX Svslem Laboratories in the USA and other coun 
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have tags embedded into the operating system code. (Pro- 
tected-mode operating systems do not allow a user to 
arbitrarily write to specific L'O locations.) 

Another use of the BIOMON is to trigger on reads and/or 
writes to I/O locations associated with accessory cards 
such as disk controllers, serial and parallel interfaces. 
Video cards, and so on. For instance, the intcrarrival rates 
of data read from a disk controller could be examined to 
determine the actual data transfer rate attained by the 
disk mechanism Ot drive controller subsystem. Additional- 
ly, by monitoring the disk controllers command registers, 
an application's disk I/O can lie fully characterized. 

Software-Based Tools 

The software-based tools used by the performance labora- 
tory allow simulation of different memory architectures. 

Cache Simulator 

The cache simulator is a trace-driven simulation based on 
the Dinero cache simulator from the University of Califor- 
nia at Berkeley. 1 The simulator takes as its input a list of 
memory accesses (trace file) and parameters describing 
the cache to be simulated. These parameters include 
cache size, line size, associativity, write policy, ami re- 
placement algorithm. The cache simulator reads the 
memory accesses from the trace file and keeps statistics 
on the cache hit rate and the total bus traffic- to and from 
main memory. When the entire trace file has been read, 
the simulator generates a report of the cache statistics. 

A trace file is generated by connecting the PMON to a 
CPU and storing all the memory accesses on the (TP 
bus to the high-capacity logic analyzer described above. 
The data collected from (he analyzer can later be down- 
loaded to a host personal computer and archived to hard 
disk. To gel useful dala from the simulator, however, the 
injiul trace file musl be long enough l.o "prime" the simu- 
lated cache. The first several thousand memory accesses 
in the trace file will be misses thai fill up the initially 
empty cache. The simulator will report artificially low hit 
rates, because in a real system the cache is never com- 



pletely empty. If the trace file is significantly longer than 
N p *. priming effects are minimized. When simulating a 
128K-byte. 2-way associative cache external to the In- 
tel486. Np is approximately 40.000.- The high-capacity 
logic analyzer mentioned above is able to store 16 million 
memory accesses from the Intel486 via the PMON. A 
trace file containing 16 million accesses results in a prim- 
ing error of less than 1% in the hit rate calculation (as- 
suming a tiii rate of approximately 90% for the 128K-hyte. 
2-way cache). 

Memory Subsystem Simulator 

The memory subsystem simulator, a program written in 
C++, is a true event-driven simulation that keeps track of 
time rather than just statistics. It builds on the cache sim- 
ulator by integrating it into a more comprehensive model 
that simulates access time to memory. It accepts a param- 
eter file that includes cache parameters. DRAM and 
SRAM access times, and other memory architecture pa- 
rameters. It also reads in a PMON trace file, although this 
one must contain all accesses (not just memory), and 
their durations so that the simulator can keep track of 
time. The result is essentially a running time for the input 
trace file, along with statistics on all aspects of the 
memory subsystem. 

This simulator can be used for making design trade-offs 
within a memory subsystem, such as cache size and orga- 
nization, IJRAM speed, interleave, page size, and write 
buffet depth. Fig. 7 shows the sample results of a 
memory subsystem simulation of relative memory per- 
formance versus external cache size for a :i:3-MIIz In- 
tel 186 running a typical DOS application. By simulating 
various design alternatives in advance, the design engi- 
neer can arrive at a memory' architecture that is tuned for 
optimum performance before committing to hardware. 

Conclusion 

The performance analysis laboratory of Ill's Personal 
Computer Croup has developed a suite of hardware and 
software tools to aid in the design process. The hardware 

•N ( , equals the number ot memo'V accesses in ihe trace file needed to till the cache 
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Cache Size (Bytes) 

Fig. 7. Sample results of a memory subsystem simulation of relative 
memory performance versus external Cache size for a 33-MHz 
Inlei48t> running a typical DOS application. 

tools give design engineers insight into the low-level per- 
formance of existing systems, and the software tools use 
the data produced by the hardware tools to predict the 
performance of future architectures. 

The performance tools were used extensively in designing 
the HP Vectra 48(3, and more recently the Veclra 486/33T. 
The tools helped show that a burst memory controller 
(described on page 78) was a better price/performance 



solution than an external memory cache for the 25-MHz 
Vectra 486, and that an externa] cache was a necessity 
for the 33-MHz Vectra 486/33T. The tools also helped pre- 
dict the performance gain of memory write buffers in a 
Vectra 486 system. This resulted in the addition of write 
buffers to the Vectra 486/33T memory architecture. 
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